KeyHelp: PHP-Einstellungen je Kunde anpassen (memory_limit, Upload, Laufzeit, Direktiven)

Ein Shop braucht mehr Arbeitsspeicher, eine Fotogalerie größere Uploads, ein Import-Skript mehr Laufzeit. In KeyHelp legen Sie diese Grenzen je Kunde fest, nicht für den ganzen Server. Diese Anleitung zeigt die Felder im Reiter „PHP“ des Kundenkontos, den Unterschied zwischen überschreibbaren und nicht überschreibbaren Direktiven und wie Sie die Wirkung im PHP-FPM-Pool und im laufenden PHP des Kunden nachweisen. Sie richtet sich an Administratoren eines Servers wie in KeyHelp installieren und absichern. Getestet haben wir mit KeyHelp 26.1.1 und PHP 8.2 auf Debian 12.

Voraussetzungen

• Ein KeyHelp-Server mit Administrator-Zugang. Getestet mit KeyHelp 26.1.1 (Build 3698) auf Debian 12.15 mit PHP 8.2.
• Ein Kundenkonto mit PHP, im Beispiel kunde1 mit der Domain kunde1.example.de.
• SSH-Zugang als root, um Pool-Datei und Wirkung zu prüfen. Die Einstellungen selbst setzen Sie im Panel.

Schritt 1: Ausgangswerte und Pool-Datei kennen

Jeder Kunde bekommt bei KeyHelp einen eigenen PHP-FPM-Pool. Die Datei liegt nicht im üblichen pool.d, sondern in einem eigenen Verzeichnis, das die php-fpm.conf zusätzlich einbindet:

grep -n "include" /etc/php/8.2/fpm/php-fpm.conf

125:include=/etc/php/8.2/fpm/pool.d/*.conf
128:include=/etc/php/8.2/fpm/pool.keyhelp.d/*.conf

Für kunde1 ist das /etc/php/8.2/fpm/pool.keyhelp.d/kunde1.conf. Der Kopf der Datei warnt: „DO NOT CHANGE ANYTHING IN THIS FILE!“ und „CHANGES WILL BE LOST ON NEXT UPDATE.“ Ändern Sie die Datei also nicht von Hand. Im Grundzustand stehen dort die Standardwerte des Panels:

php_admin_value[memory_limit] = 128M
php_admin_value[max_execution_time] = 60
php_admin_value[post_max_size] = 72M
php_admin_value[upload_max_filesize] = 64M
php_admin_value[open_basedir] = /home/users/kunde1/www:/home/users/kunde1/files:/home/users/kunde1/tmp

Wichtig ist das Wort php_admin_value. So gesetzte Werte lassen sich laut PHP-Handbuch nicht per ini_set() überschreiben. Mit php_value gesetzte Werte dagegen schon, Schritt 5 zeigt das im Test. Genau diese Unterscheidung steuern Sie im Panel.

Verifizieren: cat /etc/php/8.2/fpm/pool.keyhelp.d/kunde1.conf zeigt den Abschnitt „; PHP immutable directives“ mit den vier Werten oben.

Schritt 2: Werte im Reiter „PHP“ eintragen

Öffnen Sie „Benutzerverwaltung“, dann „Kundenkonten“ und klicken Sie beim Kunden auf Bearbeiten. Das Formular hat die Reiter „Allgemein“, „Kontaktdaten“, „Ressourcen“, „Berechtigungen“, „PHP“, „PHP-FPM“ und „Erweiterte Einstellungen“. Im Reiter „PHP“ stehen die vier Pflichtfelder mit Erklärung:

• memory_limit: Arbeitsspeicher je Skript. Laut Hilfetext steht -1 für keine Begrenzung, als Abkürzungen gelten K, M und G.
• max_execution_time: Laufzeit in Sekunden.
• post_max_size: Größe aller POST-Daten. Der Hilfetext empfiehlt einen Wert größer als upload_max_filesize und kleiner als memory_limit.
• upload_max_filesize: Größe einer einzelnen hochgeladenen Datei.

Im Test haben wir 256M, 120, 136M und 128M eingetragen. Darunter folgen open_basedir, disable_functions, sendmail_from und Umgebungsvariablen. Ändern Sie open_basedir und disable_functions nur mit gutem Grund: open_basedir beschränkt laut Hilfetext die Dateien, auf die PHP zugreifen kann, disable_functions deaktiviert Funktionen aus Sicherheitsgründen. Speichern Sie das Formular. Die Meldung lautet „Der Benutzer kunde1 wurde aktualisiert. Die Änderungen werden in wenigen Augenblicken wirksam.“

Verifizieren: Nach dem Speichern zeigt der Reiter „PHP“ die neuen Werte. In der Pool-Datei stehen sie erst etwas später (Schritt 4).

Schritt 3: Zusätzliche Direktiven, überschreibbar oder nicht

Unter „Zusätzliche PHP-Anweisungen“ gibt es zwei Textfelder. Die Syntax ist laut Hilfetext dieselbe wie in einer php.ini, also eine Direktive pro Zeile in der Form name = wert. Laut Hilfetext haben die Einträge Vorrang vor den Feldern darüber.

• „Nicht überschreibbare Direktiven“ landen als php_admin_value im Pool. Der Kunde kann sie nicht ändern. Im Test: max_input_vars = 3000.
• „Überschreibbare Direktiven“ landen als php_value. Sie gelten als Startwert, der Kunde darf sie im Code oder per .user.ini ändern. Im Test: max_execution_time = 120 und display_errors = Off.

Das Beispiel aus dem Hilfetext zeigt den typischen Zweck: Soll ein Kunde max_execution_time selbst erhöhen dürfen, tragen Sie die Direktive bei den überschreibbaren ein.

Verifizieren: Nach dem Speichern stehen beide Felder unverändert im Formular. Was daraus in der Pool-Datei wird, zeigt Schritt 4.

Schritt 4: Wirkung in der Pool-Datei prüfen

Unmittelbar nach dem Speichern trug die Pool-Datei noch den alten Zeitstempel. Rund 40 Sekunden nach dem Speichern war sie neu geschrieben, und das Journal zeigte das Neuladen von PHP-FPM:

Oct 01 17:48:02 server.example.de systemd[1]: Reloading php8.2-fpm.service - The PHP 8.2 FastCGI Process Manager...
Oct 01 17:48:02 server.example.de systemd[1]: Reloaded php8.2-fpm.service - The PHP 8.2 FastCGI Process Manager.

Der relevante Teil der Pool-Datei danach (ohne disable_functions, gekürzt um die Zeilen für upload_tmp_dir, soap.wsdl_cache_dir und sendmail_path):

sed -n "/; PHP immutable/,\$p" /etc/php/8.2/fpm/pool.keyhelp.d/kunde1.conf | grep -v disable_functions

; PHP immutable directives
php_admin_value[memory_limit] = 256M
php_admin_value[post_max_size] = 136M
php_admin_value[upload_max_filesize] = 128M
php_admin_value[open_basedir] = /home/users/kunde1/www:/home/users/kunde1/files:/home/users/kunde1/tmp
php_admin_value[max_input_vars] = 3000

; PHP mutable directives
php_value[session.save_path] = /home/users/kunde1/tmp/
php_value[max_execution_time] = 120
php_value[display_errors] = 

Drei Dinge fallen auf. Erstens ist max_execution_time aus dem festen Teil verschwunden und steht jetzt nur noch als php_value im änderbaren Teil, weil die überschreibbare Direktive Vorrang hat. Zweitens wurde aus display_errors = Off ein leerer Wert. Für PHP ist das ebenfalls „aus“, im Test lieferte ini_get("display_errors") einen leeren String. Drittens erzeugt KeyHelp aus dem Feld nur Zeilen, die es als Direktive erkennt, mehr dazu unter „Typische Fehler“.

Verifizieren: ls -la /etc/php/8.2/fpm/pool.keyhelp.d/kunde1.conf zeigt eine Uhrzeit nach Ihrem Speichern, und journalctl -u php8.2-fpm --since "-5min" enthält „Reloaded php8.2-fpm.service“.

Schritt 5: Wirkung im Kundenkontext nachweisen

Die Pool-Datei sagt, was gelten soll. Was tatsächlich gilt, zeigt nur PHP im Kundenkontext, also über den Webserver und den Pool des Kunden. Legen Sie dazu eine Testdatei im Webspace an:

cat > /home/users/kunde1/www/info.php <<'EOF'
<?php
foreach (["memory_limit","max_execution_time","post_max_size","upload_max_filesize","max_input_vars","display_errors"] as $k) {
  echo $k, " = ", var_export(ini_get($k), true), "\n";
}
echo "ini_set memory_limit: ", var_export(ini_set("memory_limit","512M"), true), " -> ", ini_get("memory_limit"), "\n";
echo "ini_set max_execution_time: ", var_export(ini_set("max_execution_time","300"), true), " -> ", ini_get("max_execution_time"), "\n";
echo "SAPI: ", php_sapi_name(), ", User: ", get_current_user(), "\n";
EOF
chown kunde1:kunde1 /home/users/kunde1/www/info.php
curl -s http://kunde1.example.de/info.php

memory_limit = '256M'
max_execution_time = '120'
post_max_size = '136M'
upload_max_filesize = '128M'
max_input_vars = '3000'
display_errors = ''
ini_set memory_limit: false -> 256M
ini_set max_execution_time: '120' -> 300
SAPI: fpm-fcgi, User: kunde1

Die Ausgabe belegt die Trennung: Der Versuch, memory_limit im Code auf 512M zu setzen, liefert false, der Wert bleibt 256M. max_execution_time dagegen ließ sich auf 300 ändern, weil es als überschreibbar eingetragen ist. Dasselbe gilt für eine .user.ini im Webspace. Mit memory_limit = 512M, max_execution_time = 300 und max_input_vars = 5000 darin blieben memory_limit und max_input_vars unverändert, max_execution_time stieg auf '300'. Allerdings nicht sofort: Der erste Aufruf direkt danach zeigte noch '120', ein Aufruf etwa 20 Sekunden später den neuen Wert. Laut PHP-Handbuch liest PHP .user.ini-Dateien nur im Abstand von user_ini.cache_ttl neu ein, im Kundenkontext gab ini_get("user_ini.cache_ttl") den Wert 300 (Sekunden) aus. Warum der Wert im Test schon früher galt, haben wir nicht untersucht. Rechnen Sie mit bis zu fünf Minuten.

Zur Kontrolle, dass die Grenzen greifen, haben wir zwei Lasttests gemacht. Ein Skript, das 300 MB belegen will, endete mit HTTP 500, im Fehlerlog der Domain (/home/users/kunde1/logs/kunde1.example.de/error.log) stand:

AH01071: Got error 'PHP message: PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 314572832 bytes) in /home/users/kunde1/www/mem.php on line 1'

268435456 Bytes sind genau 256M. Beim Upload kam eine 100-MB-Datei mit Fehlercode 0 an, eine 130-MB-Datei mit Fehlercode 1. Fehlercode 1 ist laut PHP-Handbuch UPLOAD_ERR_INI_SIZE, die Datei ist größer als upload_max_filesize, hier 128M.

100m: 1 Datei(en), Fehlercode: 0
130m: 1 Datei(en), Fehlercode: 1

Löschen Sie Testdateien wie info.php danach wieder, sie verraten Konfigurationsdetails.

Verifizieren: Die Testdatei zeigt SAPI: fpm-fcgi und den Kundennamen als Benutzer sowie Ihre Werte aus dem Panel.

Typische Fehler

Einheit falsch geschrieben

Wir haben bei memory_limit 256MB eingetragen. KeyHelp lehnt das ab: „Ungültige Angabe im PHP-Einstellungs-Feld memory_limit.“ Richtig ist 256M, wie es der Hilfetext mit K, M und G vorgibt.

php -i zeigt andere Werte

Wer als Kunde auf der Kommandozeile php -i aufruft, sieht nicht die Werte aus dem Panel. Im Test lieferte sudo -u kunde1 php -i die CLI-Konfiguration aus /etc/php/8.2/cli/php.ini:

Loaded Configuration File => /etc/php/8.2/cli/php.ini
max_execution_time => 0 => 0
memory_limit => -1 => -1
upload_max_filesize => 2M => 2M

Die Panel-Werte gelten nur im FPM-Pool, also für Aufrufe über den Webserver. Prüfen Sie deshalb immer mit einer Datei im Webspace wie in Schritt 5.

post_max_size größer als memory_limit

Der Hilfetext empfiehlt, post_max_size kleiner als memory_limit zu halten. Erzwungen wird das nicht: post_max_size 300M bei memory_limit 256M speicherte KeyHelp ohne Warnung mit „Der Benutzer kunde1 wurde aktualisiert. Die Änderungen werden in wenigen Augenblicken wirksam.“ und schrieb php_admin_value[post_max_size] = 300M in den Pool. Die Plausibilität müssen Sie selbst prüfen.

Ungültige Zeile in den Direktiven

Eine Zeile gibtsnicht ohne Gleichheitszeichen im Feld „Nicht überschreibbare Direktiven“ nahm KeyHelp ebenfalls ohne Meldung an. In der Pool-Datei tauchte sie nicht auf, PHP-FPM lief nach dem Neuladen weiter. Tippfehler fallen also nicht auf, prüfen Sie nach jeder Änderung die Pool-Datei.

Änderung wirkt nicht sofort

Zwischen Speichern und Wirkung lagen im Test 10 bis 40 Sekunden. Wer sofort testet, sieht noch die alten Werte. Bei .user.ini kommt die Wartezeit von PHP hinzu.

Häufige Fragen

Kann der Kunde die Werte selbst ändern?

Nur die Direktiven, die Sie unter „Überschreibbare Direktiven“ eintragen. Die vier Felder oben und die nicht überschreibbaren Direktiven setzt KeyHelp als php_admin_value, Änderungen per ini_set() oder .user.ini blieben im Test wirkungslos.

Gelten die Werte für alle Domains des Kunden?

Die Einstellungen hängen am Kundenkonto und landen im Pool des Kunden. Im Test hatte der Kunde einen Pool [kunde1] für seine Domain. Unterschiedliche Werte je Domain desselben Kunden haben wir nicht geprüft.

Wie viel memory_limit ist sinnvoll?

Das hängt von der Anwendung und vom Arbeitsspeicher des Servers ab. Bedenken Sie, dass jeder PHP-Prozess des Kunden bis zu diesem Wert belegen darf. Wie viele Prozesse gleichzeitig laufen dürfen, steht in der Pool-Datei unter pm.max_children (im Test 3). Den Reiter „PHP-FPM“ haben wir in dieser Anleitung nicht geprüft.

Wo stelle ich die Standardwerte für neue Kunden ein?

In der Datenbank gibt es neben dem Eintrag für kunde1 einen Standarddatensatz mit denselben Grundwerten (128M, 60, 72M, 64M). Wo die Oberfläche ihn bearbeiten lässt, haben wir in diesem Test nicht geprüft.

Testumfang

Wir haben auf KeyHelp 26.1.1 mit PHP 8.2 die vier Grenzwerte und beide Direktivenfelder eines Kunden geändert und die Wirkung in der Pool-Datei, per Testdatei im Webspace, per ini_set(), .user.ini, Speicher- und Uploadtest geprüft. Auffällig: Ungültige Direktiven und unplausible Größen nimmt KeyHelp ohne Warnung an. Andere PHP-Versionen und Werte je Domain haben wir nicht getestet. Prüfen Sie nach jeder Änderung die Pool-Datei.

Fazit

KeyHelp setzt PHP-Grenzen je Kunde sauber im eigenen FPM-Pool um, und die Trennung zwischen festen und vom Kunden änderbaren Direktiven funktioniert wie beschrieben. Die Schwachstelle ist die Eingabeprüfung: Einheiten werden kontrolliert, unplausible Kombinationen und Tippfehler in den Direktiven nicht. Wer nach dem Speichern kurz wartet, die Pool-Datei ansieht und die Werte mit einer kleinen PHP-Datei im Webspace gegenprüft, weiß sicher, welche Grenzen die Anwendung des Kunden wirklich hat.

Weiterführende Anleitungen und Quellen

• KeyHelp installieren und absichern
• Upload-Größe in WordPress erhöhen: PHP- und Serverlimits richtig anpassen
• PHP-FPM-Pools für WordPress richtig dimensionieren
• Keyweb: KeyHelp, alle Funktionen im Überblick
• PHP-Handbuch: Wie man Konfigurationseinstellungen ändert (php_value und php_admin_value)
• PHP-Handbuch: Fehlercodes beim Datei-Upload
• PHP-Handbuch: .user.ini-Dateien