PHP-Erweiterungen fallen aus, sobald php.ini vorhanden (STRATO Managed Server)

[eddie]

Hallo ihr alle,

leider bin ich seit ein paar Monaten bei STRATO, mit einem Managed Server. Der ist bisher auch passabel gelaufen (vom üblen Support abgesehen).

Jetzt wollte ich aber ein paar Anpassungen an der Konfiguration vornehmen, z.B. die Session-Lifetime verlängern. Das geht aber offenbar nur, indem ich eine php.ini anlege.

Aber in dem Moment wo ich das tue, falle automatisch alle Erweiterungen aus, die ich im regulären Konfigurationsmenü aktiviert hatte, bspw. mbstring oder mysqli. Sprich: die Seite ist platt, weil keine Datenbankverbindung mehr möglich ist.

Auch mit folgenden Einträgen in der php.ini konnte ich da nichts ändern:

extension = "mbstring.so" extension = "mysqli.so"

Habt Ihr eine Idee, wie ich es hinbekommen kann, bspw. session.gc_maxlifetime zu ändern, ohne dabei gleich alle Extensions zu verlieren???

[Raketenwilli]

Hallo ihr alle,

leider bin ich seit ein paar Monaten bei STRATO, mit einem Managed Server. Der ist bisher auch passabel gelaufen (vom üblen Support abgesehen).

Soso. (Der kann nur mit dem arbeiten, was er übermittelt bekommt.)

Jetzt wollte ich aber ein paar Anpassungen an der Konfiguration vornehmen, z.B. die Session-Lifetime verlängern. Das geht aber offenbar nur, indem ich eine php.ini anlege.

Gab es etwa keine? Wenn doch: Warum änderst Du DIESE nicht punktuell ab?

Auch mit folgenden Einträgen in der php.ini konnte ich da nichts ändern:

extension = "mbstring.so" extension = "mysqli.so"

Habt Ihr eine Idee, wie ich es hinbekommen kann,

phpinfo() kucken.

bspw. session.gc_maxlifetime zu ändern, ohne dabei gleich alle Extensions zu verlieren???

Ich hab ein Handbuch. Da steht u.a. das Beispiel #2.

Mehr kann nicht nicht „sagen“, weil Du extrem sparsam mit Infos bist. Du schreibst weder, wo Deine php.ini ist noch was in dieser steht, noch was phpinfo() oder das error.log „austut“.

[Raketenwilli]

Du schreibst weder, wo Deine php.ini ist noch was in dieser steht, noch was phpinfo() oder das error.log „austut“.

Und ja: Auch Hinweise zum Webserver (Apache, NGNIX,...) und zur Ausführungsweise von PHP (Modul, FPM, CGI) sind absolut notwendig, weil diese jeweils (eine) andere PHP.ini)s) nutzen und ggf. einen Neustart des Servers brauchen um wirksam zu werden. Sonst gibt es notwendigerweise nur den bereits geposteten Link zum Handbuch...

Wenn Du es nicht weißt: Ein simples Skript mit

<?php
phpinfo();
?>

oder mein Replacement (gerade für NGINX erweitert) gibt Auskunft.

[eddie]

Hey Willi,

sorry, dass ich nicht genauere Infos gegeben hab. Manchmal erwisch ich mich dabei, zu denken, das langt schon so :-/ Tut's halt nicht, haste Recht.

Nur hat sich's jetzt nach stundenlanger Suche erledigt. Ich konnte mit der vorhanden Direktive extension_dir rausfinden, wo Strato die Erweiterungen liegen hat, und vor allem, wie die heißen. Mittels extension = "xxx.so" konnte ich die dann einbinden.

Hat dann immer noch nicht funktioniert, und mich in stundenlanges Debugging gestürzt. Erst als ich folgende Kommentarzeile entfernt habe, ging's dann:

# STRATO-Default: 2M; BEACHTE: upload_max_filesize wird auch in JavaScript verwendet! Bei Änderungen dort bitte auch updaten!

Für mich ist das ein Kommentar. Auch folgender Kommentar hat die Konfig zerschossen:

; BEACHTE: upload_max_filesize wird auch in JavaScript verwendet! Bei Änderungen dort bitte auch updaten!

Irgendwann hatte ich dann zugegebenermaßen keinen Bock mehr (weil pro Änderung muss man jedes Mal Apache neu starten), und hab das alles rausgehauen. Jetzt passt's, aber ganz verstanden hab ich's jetzt auch nicht...

Danke trotzdem, Willi!

Martin

[Raketenwilli]

Hat dann immer noch nicht funktioniert, und mich in stundenlanges Debugging gestürzt. Erst als ich folgende Kommentarzeile entfernt habe, ging's dann:

# STRATO-Default: 2M; BEACHTE: upload_max_filesize wird auch in JavaScript verwendet! Bei Änderungen dort bitte auch updaten!

Ganz ohne zu probieren: Kommentare werden im ini-Format „offiziell“ durch ein ; eingeleitet und in der php.ini wird das auch eindeutig so und nur so beschrieben.

Für mich ist das ein Kommentar. Auch folgender Kommentar hat die Konfig zerschossen:

Nicht dokumentierte Vermutungen anzuwenden birgt das Risiko eines Fehlschlages.

; BEACHTE: upload_max_filesize wird auch in JavaScript verwendet! Bei Änderungen dort bitte auch updaten!

Hm. Der ist auf deutsch. Und auf keinen Fall im Original enthalten. Aber, so wie Du ihn präsentierst ist es eben ein Kommentar - und von der Sorte gibt es genau 1501 in der von mir geprüften php.ini. Das kann also nicht die Ursache gewesen sein:

grep -e '^;'  /etc/php/8.2/cli/php.ini | wc -l
1501

Irgendwie hab ich den Eindruck, Du stocherst im Nebel. An der Zeile lag es jedenfalls nicht.

[Rolf B]

Hallo Raketenwilli,

kann es sein, dass Strato eine eigene Logik vorschaltet und versucht, die php.ini auf Userseite zu validieren oder "unerwünschte" INIs vom System fernzuhalten? Und der Validator ist fritte?

Eddie-Martin,

hast Du mal geguckt, ob in der php.ini von Strato die Möglichkeit vorgesehen ist, eine .user.ini zu verwenden? Ich halte es nämlich für kritisch, die Strato-INI einfach entfallen zu lassen, ohne sie komplett zu klonen.

Rolf

[Raketenwilli]

Hallo Raketenwilli,

kann es sein, dass Strato eine eigene Logik vorschaltet und versucht, die php.ini auf Userseite zu validieren oder "unerwünschte" INIs vom System fernzuhalten?

Womöglich (vermutlich) werden Einstellungen wieder „überladen“.

Ich kann es nicht bei Strato testen ... aber bei mir:

php -c /etc/php/8.2/cli/php.ini --ini

(Die ini-Datei muss an die lokalen Umstände angepasst werden!)

Ausgaben:

Configuration File (php.ini) Path: /etc/php/8.2/cli
Loaded Configuration File:         /etc/php/8.2/cli/php.ini
Scan for additional .ini files in: /etc/php/8.2/cli/conf.d
Additional .ini files parsed:      /etc/php/8.2/cli/conf.d/10-opcache.ini,
/etc/php/8.2/cli/conf.d/10-pdo.ini,
/etc/php/8.2/cli/conf.d/15-xml.ini,
/etc/php/8.2/cli/conf.d/20-calendar.ini,
/etc/php/8.2/cli/conf.d/20-ctype.ini,
/etc/php/8.2/cli/conf.d/20-dom.ini,
/etc/php/8.2/cli/conf.d/20-exif.ini,
/etc/php/8.2/cli/conf.d/20-ffi.ini,
/etc/php/8.2/cli/conf.d/20-fileinfo.ini,
/etc/php/8.2/cli/conf.d/20-ftp.ini,
/etc/php/8.2/cli/conf.d/20-gettext.ini,
/etc/php/8.2/cli/conf.d/20-iconv.ini,
/etc/php/8.2/cli/conf.d/20-mbstring.ini,
/etc/php/8.2/cli/conf.d/20-phar.ini,
/etc/php/8.2/cli/conf.d/20-posix.ini,
/etc/php/8.2/cli/conf.d/20-readline.ini,
/etc/php/8.2/cli/conf.d/20-shmop.ini,
/etc/php/8.2/cli/conf.d/20-simplexml.ini,
/etc/php/8.2/cli/conf.d/20-sockets.ini,
/etc/php/8.2/cli/conf.d/20-sysvmsg.ini,
/etc/php/8.2/cli/conf.d/20-sysvsem.ini,
/etc/php/8.2/cli/conf.d/20-sysvshm.ini,
/etc/php/8.2/cli/conf.d/20-tokenizer.ini,
/etc/php/8.2/cli/conf.d/20-xmlreader.ini,
/etc/php/8.2/cli/conf.d/20-xmlwriter.ini,
/etc/php/8.2/cli/conf.d/20-xsl.ini

Man kann das mit folgendem Testskript auch auf dem Webserver und PHP als Modul oder FPM herausfinden und mit den Erwartungen vergleichen:

<?php
### file: test.php
### Leerzeilen sind Abicht!
header('Content-Type:text/plain');
print php_ini_loaded_file();
?>

------------------------------------------------------------------

<?php
print_r(php_ini_scanned_files());
?>

(phpinfo() liefert diese Infos ebenfalls.)

Und der Validator ist fritte?

Ist er womöglich. Jedenfalls hab ich grad in einem Schnelltest trotz provozierten Fehlers keine Fehlermeldung gesehen…

Nachtrag:

Genau mit den beiden obigen Verfahren findet man auch die Fehler:

php -c /etc/php/8.2/cli/php.ini --ini
PHP:  syntax error, unexpected '!' in /etc/php/8.2/cli/php.ini on line 3

In Zeile 3 hab ich „Mist!“ notiert. Steht da nur „Mist“ geht es durch…

[Rolf B]

Hallo Raketenwilli,

diese additional ini files sollten die Haupt-INI aber ergänzen und nicht überschreiben, oder?

Jetzt kann es natürlich sein, dass der TO eine Komplett-Ini in sein Web gestellt hat und keine Addon-Ini, die nur die zu ergänzenden Einträge enthält.

Rolf

[Raketenwilli]

diese additional ini files sollten die Haupt-INI aber ergänzen und nicht überschreiben, oder?

Hm. Die generelle Linux-Empfehlung lautet:

Die mit PHP installierte Haupt-INI kann (wie alle anderen installierten Konfig-Dateien in /etc/) bei einem Update mehr oder weniger automatisch überschrieben werden, sollte deshalb „unberührt" bleiben. Und genau deshalb sollen eigene Änderungen im conf.d-Ordner in einer eigenen Datei mit hoher Nummer (>90) als Vorsatz-String erfolgen und frühere Einstellungen (aus den automatisch installierten ini-Dateien) überladen. Oder eben projektbezogene Ini-Dateien verwendet werden…

Darauf achten, dass die ini-Abschnitte (etwas wie [FOO]) mit notiert werden, denn die Doc sagt, dass diese womöglich irgendwann beachtet werden.

[x] Hab mein Replacement für phpinfo() angepasst, das zeigt jetzt auch INIs an. Version ist jetzt 2.1.0

[Raketenwilli]

Hat dann immer noch nicht funktioniert, und mich in stundenlanges Debugging gestürzt. Erst als ich folgende Kommentarzeile entfernt habe, ging's dann:

# STRATO-Default: 2M; BEACHTE: upload_max_filesize wird auch in JavaScript verwendet! Bei Änderungen dort bitte auch updaten!

Ganz ohne zu probieren: Kommentare werden im ini-Format „offiziell“ durch ein ; eingeleitet und in der php.ini wird das auch eindeutig so und nur so beschrieben.

Mit #eingeleitete Kommentare sind mindestens seit 2010 deprecated… inzwischen wohl verboten.