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

    Hallo,


    ab sofort stehen neue Versionen unserer PHP-Pakete für Debian/Ubuntu zum Download bereit (PHP-Version 5.6.37, 7.0.31, 7.1.20 und 7.2.8).


    Bei diesen Paketen gibt es einige grundlegende Neuerungen:

    • die Pakete werden nun komplett als "ordentliche" PHP-Pakete gebaut, d.h. alle Konfigurationsdateien (u.a. /opt/php-X.X/etc/) werden als solche verwaltet.
      Während des Upgrades wird mittels Prüfsummen verglichen, ob die .ini-Dateien früherer Installationen unverändert sind und dann ggf. stillschweigend ersetzt, ansonsten wird während des Upgrades gefragt, ob eine neuere Version davon installiert werden soll.
    • die PHP-Pakete enthalten viele weitere Extensions, und viele bisherige Extensions sind nun als separate Module (Shared Objects) ausgelagert - die können somit einzeln aktiviert/deaktiviert werden.
    • PHP 5.6 steht nun auch für Ubuntu 16.04 und 18.04 bereit
    • APCu und ImageMagick steht nun auch für alle 7.x-Versionen zur Verfügung
    • alle Pakete ab PHP 5.6 registrieren sich nun selbständig am LiveConfig (via /etc/liveconfig/lua.d), ein Eintrag in die custom.lua ist somit nicht mehr notwendig. Für ältere Pakete (5.5, 5.4, 5.3, evtl 4.4) wird das voraussichtlich in den nächsten Wochen folgen.
    • die neuen Pakete (PHP 5.6/7.0/7.1/7.2) installieren nun ein Init-Script und ggf. einen systemd-Service, mit dem künftig PHP-FPM-Instanzen automatisch gestartet werden können. Die nächste LiveConfig-Version (v2.7) wird nämlich FPM unterstützen. :) (Daher ist dieses PHP-Update für LiveConfig wichtig, da für FPM eine etwas komplexere Registrierung an LiveConfig erforderlich ist)


    Im Wiki folgt in Kürze noch eine Beschreibung, wie man zusätzliche PHP-Versionen unter CentOS bequem hinzufügen kann.


    Sollte es während des Updates Probleme geben, schicken Sie uns bitte alle Bildschirmmeldungen die während des "apt upgrade" aufgetreten sind.
    Im Notfall hilft es, die jeweilige PHP-Version komplett vom Server zu entfernen ("apt purge php-X.X-opt") und neu zu installieren.
    Wir haben die Upgrades auf allen unterstützten Distributionen manuell durchgetestet und keine Fehler oder Warnungen dabei erhalten.
    AUSNAHME: wer vorher eine PHP-Version aus dem "debian-test"-Repository installiert hatte, muss i.d.R. nach dem Update die Datei /opt/php-X.X/etc/conf.d/xml.ini löschen.


    Um zu testen, ob eine bestimmte PHP-Version korrekt ausgeführt werden kann (inkl. aller Module), einfach wie folgt aufrufen: /opt/php-X.X/bin/php -v


    Viele Grüße


    -Klaus Keppler

    Nicht dass hier ein Mißverständnis vorliegt: wir reden hier nicht von Tests.


    Die neuen PHP-Pakete sind - wie bei uns üblich - zuerst im "debian-test"-Repository gelandet und wurden von dort aus durch uns und einige einzelne Kunden ausführlich durchgetestet.
    Nachdem wir keine Probleme haben feststellen können, haben wir die Pakete in das normale Repository übernommen.


    Die Hinweise sind nur für den Fall, dass irgendwo Probleme auftauchen sollten, die in unseren Umgebungen nicht aufgetreten sind.

    Zitat von robby

    Da muss ich direkt mal fragen. "Eigene" PHP-Versionen kann man aber trotzdem nach wie vor nutzen, auch mit FPM dann?


    Gut, gut....das habe ich dann wohl missverstanden. Ansonsten kann ich nur noch mal bestätigen. Mir sind keine Probleme aufgefallen, weder beim Updaten noch bei einer frischen Installation.

    Hallo zusammen,


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


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


    nur noch


    Code
    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

    Zitat von lulatsch66

    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". :cool:


    Viele Grüße


    -Klaus Keppler

    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.

    Zitat von sTeaLth

    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.

    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. :)

    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:


    Code
    ./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.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden