Froxlor und php Upgrade

  • Hallo,


    nachdem ich jetzt auf Debian 9 upgegraded habe und die neueste Version von Froxlor ebenfalls nutzen kann, möchte ich jetzt die neueste PHP Version (eine 7.x) installieren. Froxlor nutzt ja noch 5.6, aber ich habe auch schon gelesen, dass es mit 7.x problemlos funktionieren soll. Deshalb würde ich gerne die 5.6 ersetzen durch 7.x. Wie muss ich da vorgehen, so dass Froxflor weiterhin funktioniert und alle anderen Anwendungen die neue Version benutzen können?


    Vg


    Albert

  • Am besten php7.0.x aus einem Debian-Repository installieren - etwa via:


    deb http://packages.dotdeb.org stretch all

    deb-src http://packages.dotdeb.org stretch all


    Etwaige Schwierigkeiten wirst Du dort sehen, wo die php5-Binary (etwa bei cronjobs) oder als shebang (erste Zeile mit "#!" im Script) eingetragen ist. Die Lösung dafür ist, einen Symlink von /usr/bin/php5 zu /usr/bin/php zu setzen.


    Aktuell ist übrigens php-7.3. Es wird mit anderen Repositories ähnlich funktionieren, aber ich weiss aufgrund Deiner vorhergehenden Postings nicht, ob Du für solche Modifikationen schon bereit bist. Zögere jedenfalls nicht, zu fragen, wenn etwas unklar ist. Das Thema ist für einen Einsteiger nicht unbedingt trivial, aber zu schaffen.


    Update: 7.3 gibt es auch auf packages.sury.org, aber es gab in diesem Forum irgendwo Vorbehalte, dieses zu nützen. Man müsste recherchieren, ob mit diesem Repository alles wieder passt.

  • Am besten php7.0.x aus einem Debian-Repository installieren - etwa via:


    deb http://packages.dotdeb.org stretch all

    deb-src http://packages.dotdeb.org stretch all

    Das sind aber nicht die offiziellen Debian-Quellen, Achtung:!:Ich wüsste keinen Grund dotdeb zu nutzen, die bieten auch nur 7.0 wie die Debian selbst, von daher sollte sich php7 einfach direkt installieren lassen über:


    Code
    apt-get install php7.0

    siehe auch: https://packages.debian.org/stretch/php7.0


    Je nachdem kann man dann php7.0-fpm oder php7.0-cgi installieren/einrichten/nutzen.


    Edit:


    dotdeb.org bietet für stretch doch gar keine Pakete an, deren Repo ist doch leer für stretch, auf der Website wird stretch auch nicht erwähnt... :/

  • Es ist natürlich möglich unterschiedliche FPM Pools für verschiedene Applikationsgruppen zu benutzen.

    Ob das allerdings Sinn macht, das Konstrukt über Froxlor zu verwalten, frage ich mich gerade. Genau so ob Froxlor das auch nutzen kann.


    Zu deb.sury.org ist mir (auch hier) nichts negatives untergekommen. Was soll damit sein eripek ?

    7.0 steht doch mittlerweile auch auf EOL. Ich würde mindestens die 7.2 installieren.

  • Auf PHP 7.0 upzudaten ist sowieso nicht mehr empfehlenswert, weil PHP 7.0 sein EOL erreicht hat -> erhält keine security fixes mehr -> die Botnetze freuen sich.

    So ganz stimmt das nicht, es gibt keinen Upstream-Support mehr. Aber Debian kümmert sich noch min. 1 Jahr nach Release des nächsten stables darum. Von daher wird php 7.0 nicht direkt sterben oder "verwaist" sein, sondern noch ein paar Jahre (sicher) unter uns weilen...

  • Es ist natürlich möglich unterschiedliche FPM Pools für verschiedene Applikationsgruppen zu benutzen.

    Ob das allerdings Sinn macht, das Konstrukt über Froxlor zu verwalten, frage ich mich gerade. Genau so ob Froxlor das auch nutzen kann.


    Zu deb.sury.org ist mir (auch hier) nichts negatives untergekommen. Was soll damit sein eripek ?

    7.0 steht doch mittlerweile auch auf EOL. Ich würde mindestens die 7.2 installieren.

    Ok. Ihr habt jedenfalls Recht mit sury.org und 7.2+. Ich hatte da irgendeine wage Erinnerung, wahrscheinlich stimmt die Information seit August eh nicht mehr... Bitte um Pardon, wenn mein Hirn auslässt.


    Zu Froxlor: AFAIK sieht es im Konstrukt mit php-fpm (mit nginx) nur einen derartigen Socket vor, man kann es wohl mit ein paar Tricks umgehen. Mit ISPconfig ginge das aus dem Stehgreif.

  • Im testing und unstable ist schon php7.3 verfügbar.

    Testing und unstable würde ich jetzt aber nicht unbedingt für ein Produktivsystem (vor allem nicht das eines vServer-Einsteigers) empfehlen. Ich sehe natürlich das Problem mit php und den Backports ein - ebenso wie, dass die Welt nicht perfekt ist.

  • Testing und unstable würde ich jetzt aber nicht unbedingt für ein Produktivsystem (vor allem nicht das eines vServer-Einsteigers) empfehlen. Ich sehe natürlich das Problem mit php und den Backports ein - ebenso wie, dass die Welt nicht perfekt ist.

    Wobei ich nicht weiß was besser ist: unstable/testing nutzen oder ein externes Repo, kommt irgendwie fast auf das gleiche heraus, security patches mag der eine schneller liefern, vertrauenswürdiger finde ich Debian, ...


    Das Problem ist hier wurde dann das falsche OS benutzt, falls man php 7.1 oder höher will. Die Philosophie von Debian ist: "alt aber bewährt", daher hinken die Versionen von Debian meist 1-2 Jahre hinterher, laufen dafür aber stabil und werden auch weiter supported falls der "offizielle" Support ausläuft. Wenn man "bleeding edge" haben will muss man sich halt selbst darum kümmern. Oder man nutzt ein entsprechendes OS, das pedant bei Debian wäre dazu wohl Ubuntu.


    Ubuntu 18.04 (LTS) hat bereits php7.2 standardmäßig: https://packages.ubuntu.com/bionic/php

  • Wobei ich nicht weiß was besser ist: unstable/testing nutzen oder ein externes Repo, kommt irgendwie fast auf das gleiche heraus, security patches mag der eine schneller liefern, vertrauenswürdiger finde ich Debian, ...

    Da hast Du Recht, und das habe ich mit der nicht perfekten Welt gemeint. Debian ist mir wegen der Featurestabilität lieber und ich würde allein deswegen Debian Ubuntu vorziehen. Gerade dann, wenn man noch Erfahrung sammelt, sind die sechs-monatigen Releasezyklen bei Ubuntu eher problematisch und bei LTS hast Du teilweise dieselbe Problematik wie bei Debian stable. (Wobei Debian mit systemd auch so ein Thema ist, wo man sich beizeiten wundert... und auf devuan schielt...). Wir kommen aber leicht off-topic. Möchtest Du für den TE den Tip nocheinmal zusammenfassen?

  • Wobei ich nicht weiß was besser ist: unstable/testing nutzen oder ein externes Repo, kommt irgendwie fast auf das gleiche heraus, security patches mag der eine schneller liefern, vertrauenswürdiger finde ich Debian, ...


    Ich finde Debian auch vertrauenswürdiger. Wobei man aber dazu sagen muss, dass der Betreiber von packages.sury.org (Ondřej Surý) einer der Debian PHP Betreuer ist. Insofern sollten die Pakete fast genauso vertrauenswürdig sein.


    Ich habe jedenfalls vor PHP von dort zu installieren (derzeit noch nicht gemacht)

  • Danke für die vielen Antworten. Jetzt noch einmal auf z.B. Ubuntu umzusteigen wäre nicht meine präferierte Lösung. Ich würde lieber auf 7.2 updaten. Welches Package wäre denn jetzt "besser": packages.sury.org oder package.dotdeb.org ?

  • Danke für die vielen Antworten. Jetzt noch einmal auf z.B. Ubuntu umzusteigen wäre nicht meine präferierte Lösung. Ich würde lieber auf 7.2 updaten. Welches Package wäre denn jetzt "besser": packages.sury.org oder package.dotdeb.org ?

    Es steht nur packages.sury.org zur Auswahl, dotdeb.org bietet keine Pakete für Stretch an und hat auch nur php7.0.

  • Habe jetzt eine neue Datei php.list in /etc/apt/sources.list.d angelegt und dort eingetragen:


    Zitat

    # Empfehlung aus dem netcup Forum, um die neuesten php Quellen zu bekommen

    deb http://packages.sury.org stretch main

    deb-src http://packages.sury.org stretch main

    Dann habe ich apt-get update aufgerufen und mit apt-cache search nach php gesucht. Dort gibt es dann nur Pakete für php7.0. Habe ich etwas falsch gemacht? Ich möchte gerne 7.2. :/