Die Direktive heißt dat
e.timezone, nicht dat
a und ist bei einer PHP 8.2 php.ini ungefähr bei Zeile 980.
In Debian 12 gibt es nur PHP 8.2 und große Versionssprünge wird es innerhalb einer Debian Version auch nicht geben. Das liegt daran das Debian eine stabile Distribution ist. Will man Software die Debian nicht selbst bereit stellt muss man externe Paketquellen einbinden, für PHP ist insbesondere
sury zu nennen. Würde ich einem Anfänger aber von abraten. PHP 8.2 wird ja unterstützt also erstmal nichts unnötig verkomplizieren.
ral9004 schrieb:
Gibt es da keine Struktur oder Gliederung die ich beachten müsste?
Die Gliederung dieser Datei ist INI, erkennbar an der Datei-Erweiterungen
.ini am Ende des Dateinamens.
Piktogramm schrieb:
Es gibt mehr als eine php.ini, mindestens je zwei für php und php-cli (php fürs Terminal) und dann nochmal zwei für php-fpm und dessen Cli-Variante.
FPM ist die Variante, davon gibt es keine "Cli-Variante". Die Varianten sind apache2, cli und fpm. Die php.ini findet sich bei Debian jeweils unter
/etc/php/<version>/<variante>/php.ini.
Etwas nervig ist aber durchaus das PHP eine extra Behandlung verlangt und die Zeitzone nochmal gesagt bekommen will anstatt einfach die gottverdammte Zeitzone aus den Systemeinstellungen zu benutzen an die sich jedes andere Programm auch hält.
axl foli schrieb:
Mit Docker/Kubernetes werden ganze Landschaften/Dienste ausgerollt.
Ja aber erst in dem Fall zeigt es auch seine wahren Stärken und eine ganze Landschaft an Diensten will er ja gar nicht.... Beim Betreiben eines einzelnen Servers fährt man mMn besser und zuverlässiger sich an die Software aus der Distribution zu halten. Da passen alle Versionen zusammen, die Konfiguration ist konsistent und ein apt upgrade oder unattended-upgrades allein reicht um alle Software auf dem System aktuell zu halten.
axl foli schrieb:
Weiterhin kannst du dir ein schickes Docker-Compose File bauen und sehr einfach weitere Dienste auf deinem Linux hosten, ganz ohne, dass die sich in die Quere kommen.
Wüsste jetzt nicht was sich da in die Quere kommt... apache2 und PHP sind ja schon von Haus aus darauf ausgelegt mehrere Websiten/Apps hosten zu können. Beachten muss man sonst eigentlich nur Ports, aber das musst du bei Docker services die du ans Internet exposen willst ja auch.
axl foli schrieb:
Dienste nach der alten Methode macht eigentlich niemand mehr. Viel zu umständlich.
Was glaubt du denn was in dem Container ist. Ziemlich häufig ein Betriebssystem wo genannte Software auf die "alte Methode" installiert wurde.
Nur dass viele Devs schlechte Sysadmins sind und von Deployment wenig Ahnung haben. Die fertigen Container images sind ziemlich mittelmäßig. Sicherheitspatzer, völlig überladen oder so minimal das man nicht debuggen kann. Dann Konfigurationen die doch nicht per Umgebungsvariable exposed sind so dass man da irgendwie reinpfuschen muss. Schleppende Updates, veraltetes Basis-OS, inkonsistente Systemkonfiguration da abweichendes OS.
Und am Ende hat man dann 17 verschiedene Versionen von OpenSSL auf seinem Server. D.h. 17x Speicherplatz belegt, 17x RAM-Verbrauch und 17x so viele Updates um eine Sicherheitslücke zu beheben. Naja, wers mag.
Fortgeschrittenen Nutzern würde ich dazu raten ihre Container selbst zu bauen, auf einem einheitlichen Basis image. Um die Container zu erstellen muss man aber eben wissen wie die Software wirklich installiert und konfiguriert wird, nicht nur den Docker compose Vorhang / Umgebungsvariablen murks.
