Komplett neue PHP-Pakete (5.6.37, 7.0.31, 7.1.20, 7.2.8)

[taenzerme]

Er hat schon wieder FPM gesagt ;-) *scnr* Großartige News!

[lulatsch66]

Hallo zusammen,

mir ist aufgefallen, dass in den neuen Paketen in php-7.1-opt/bin/ bzw. php-7.2-opt/bin/ jetzt statt

pear  peardev  pecl  phar  phar.phar  php  php-cgi  php-config  phpdbg  phpize

nur noch

pear  phar  phar.phar  php  php-cgi

enthalten sind. Mangels pecl lässt sich so z.B. xdebug nicht mehr installieren. Gibt es dafür einen Grund bzw. einen workaround?

Danke schon mal!
Falko

[kk]

Mangels pecl lässt sich so z.B. xdebug nicht mehr installieren. Gibt es dafür einen Grund bzw. einen workaround?

Der Grund ist: pecl macht nur dann Sinn, wenn man auch Entwicklertools (gcc usw.) auf dem Server installiert hat. In manchen Hostingumgebungen ist das nicht erwünscht.
Deshalb stecken pecl (sowie alle notwendigen Header etc.) nun in separaten "-dev"-Paketen, also z.B. "php-7.2-opt-dev".

Viele Grüße

-Klaus Keppler

[aziegler]

oh, sogar mit changelog nun die Pakete, top :-D

[sTeaLth]

Ich habe die "alten" Debian Packete unter "Ubuntu 14.04.5 LTS" genutzt. Kann mir jemand sagen, ob die neuen da weiterhin funktionieren? Beim Update sieht es so aus, als würde er die Packete nur entfernen wollen.

Die folgenden Pakete haben verletzte Abhängigkeiten:
php-7.2-opt : Hängt ab von: libjpeg62-turbo (>= 1.3.1) , welches ein virtuelles Paket ist.
Hängt ab von: libpcre3 (>= 1:8.35) aber 1:8.31-2ubuntu2.3 ist installiert.
Hängt ab von: libstdc++6 (>= 4.9) aber 4.8.4-2ubuntu1~14.04.4 ist installiert.
Hängt ab von: libsystemd0 , welches ein virtuelles Paket ist.
php-7.0-opt : Hängt ab von: libjpeg62-turbo (>= 1.3.1) , welches ein virtuelles Paket ist.
Hängt ab von: libpcre3 (>= 1:8.35) aber 1:8.31-2ubuntu2.3 ist installiert.
Hängt ab von: libsystemd0 , welches ein virtuelles Paket ist.
Die folgenden Aktionen werden diese Abhängigkeiten auflösen:

Entfernen der folgenden Pakete:
1) php-7.0-opt
2) php-7.2-opt

[kk]

Ich habe die "alten" Debian Packete unter "Ubuntu 14.04.5 LTS" genutzt.

Für Ubuntu 14 haben wir nie PHP-Pakete angeboten - falls die da funktioniert haben sollten, war das purer Zufall (& viel Glück).
Sie können durchaus versuchen, die neuen Pakete manuell zu installieren (das geht vermutlich nur mit Download der einzelnen .deb-Dateien und dann "dpkg -i", evtl mit einer --force-Option). Aber alles ohne Garantie - das wird von uns NICHT unterstützt.

Compiliert wurden die "neuen" Pakete auf den selben Servern wie bisher. Das neue Packaging von Debian/Ubuntu nimmt die Abhängigkeiten allerdings viel genauer in die Paketinformationen mit auf.

[aziegler]

Ich habe die "alten" Debian Packete unter "Ubuntu 14.04.5 LTS" genutzt.

Auf 16.04 updaten wäre sowieso angesagt, und dann funktionieren die Pakete auch ;-)

[sTeaLth]

Auf 16.04 updaten wäre sowieso angesagt, und dann funktionieren die Pakete auch ;-)

Ja der Plan steht auch schon, aber ich muss noch ein paar "Sonderlocken" aus dem System migrieren. Dann werde ich das jetzt wohl doch schneller angehen.

Danke nochmals

[kk]

Die PHP-Pakete wurden erneut aktualisiert (5.6.37-5, 7.0.31-4, 7.1.20-4, 7.2.8-4).
Folgende Änderungen gibt es mit dem Update:

• für PHP-FPM-Logs wird Logrotate konfiguriert (/etc/logrotate.d/php##-fpm)
• in die Lua-Konfigurationsdateien (/etc/liveconfig/lua.d/php##.lua) wurden die FPM-Parameter "start" und "stop" aufgenommen (in manchen Fällen muss LiveConfig die Prozesse ausdrücklich neu starten können)

Das war's auch schon.

[antondollmaier]

So - habe einen Fehler gefunden, der leider größere Auswirkungen hatte.

Mit 5.6.37 (den neuen Paketen) ist per Default suhosin aktiv, das zuvor deaktiviert war:

./php-5.6-opt_5.6.35-1+stretch1_amd64/opt/php-5.6/etc/conf.d/suhosin.ini.disabled
./php-5.6-opt_5.6.36-1+stretch1_amd64/opt/php-5.6/etc/conf.d/suhosin.ini.disabled
./php-5.6-opt_5.6.37-3+stretch1_amd64/opt/php-5.6/etc/conf.d/suhosin.ini
./php-5.6-opt_5.6.37-5+stretch1_amd64/opt/php-5.6/etc/conf.d/suhosin.ini

Das hätte definitiv als "breaking change" ins Changelog müssen.

Wir haben die "max_input_vars" erhöht - durch das aktive Suhosin wurde der Wert zwar übernommen, Suhosin hat über "suhosin.post.max_vars" bzw "suhosin.request.max_vars" die Änderung effektiv blockiert.

Da auch keinerlei Logging aktiv ist, gab es keinerlei Hinweise auf die Änderung.