PHP-Version für nextcloud auf Debian-Server

  • Hallo zusammen,


    auf einem netcup-Rootserver mit Debian-Stretch nutze ich unter anderem eine veraltete Version von nextcloud. Nun wollte ich nextcloud updaten auf das aktuelle Release (16.0.1). Zu meiner Überraschung steht in der nextcloud-Dokumentation im Abschnitt "Prerequisites for manual installation", daß für nextcloud 16 eine der drei folgenden PHP-Versionen benötigt wird: 7.1, 7.2 oder 7.3.


    Debian-Stretch bietet in den Standard-Repositories jedoch maximal Version 7.0 von PHP an. Auf meine Anfrage bei den nextcloud-Leuten wurde ich darüber informiert, daß die Version 7.0 von PHP bereits "end of life" ist und nicht mehr supported wird. Auch (Security-)Updates gibt es wohl keine mehr für 7.0.


    Bisher war mein Verständnis das, daß es sich bei Debian um eine sehr verbreitete Server-Distribution handelt und deshalb eine gute Wahl zum Hosting von Web-Applikationen darstellt. Daß man mit dem aktuellen Debian-Release bei einer nicht mehr unterstützten PHP-Version landet und deshalb aktuelle Software, die PHP voraussetzt, nicht mehr nutzen kann, hätte ich eigentlich nicht für möglich gehalten.


    An Lösungsvorschlägen wurden mir bisher folgende unterbreitet:

    1. PHP 7.2 installieren aus einem mir unbekannten Repository (packages.sury.org/php/)
    2. warten auf das nächste Debian-Release "Buster"

    Zu Vorschlag Nummer 1: Ein non-standard-Repository einzubinden, mag ich eigentlich grundsätzlich nicht. Woher soll ich wissen,

    • ob man dieser Software überhaupt trauen kann?
    • ob darüber (Security-)Updates ausgeliefert werden?
    • ob ich mir zukünftig damit irgendwelche (Kompatibilitäts-)Probleme einhandeln werde?
    • ob es das Repository in einem Monat oder in einem Jahr überhaupt noch geben wird?

    Und mit Vorschlag Nummer 2 kann mein Problem nicht jetzt, sondern erst zu einem aktuell noch unbekannten Zeitpunkt in der Zukunft gelöst werden.


    Aktuell läßt mich diese Situation etwas ratlos zurück. Sollte ich mich ggf. nach einer anderen Server-Distribution umschauen?


    Vielleicht habt Ihr schon mal ein ähnliches Problem gehabt? Und im Idealfall auch irgendwie gelöst? - Für Kommentare, Erfahrungsberichte, Meinungen und Vorschläge bin ich auf jeden Fall dankbar.

  • Hallo @Kraeutergarten,

    • packages.sury.org/php/

    Dieses Repo wird von jemanden betrieben, der auch die offiziellen Debian Pakete betreut.

    das ist natürlich eine wichtige Info! - Besten Dank. Das ändert die Situation schon mal ein wenig.


    Wenn ich PHP 7.2 aus diesem Repo installieren würde, müßten dann auch alle PHP-Module wie z.B. php-curl, php-gd, php-imagick, php-mbstring, php-mysql, php-zip, usw. aus diesem Repository kommen? Falls ja: Kann ich vorher irgendwie überprüfen, ob es überhaupt alle PHP-Module in diesem Repository gibt, die ich für meine Anwendungen (u.a. nextcloud, ttrss sowie ein Forum) benötige?

  • Das Problem muss zwingend lösbar sein, weil die ganzen Webhostings alle unter Debian laufen und PHP 7.1, 7.2 und 7.3 da zur Verfügung stehen. ;)

    Diese Pakete werden entweder von Netcup kompiliert oder von Dritten, die zumindest auch nicht wesentlich vertrauenswürdiger sind als ein Debian-Entwickler. Wenn es nicht womöglich sogar der selbe ist.

    Ansonsten hast du immer die Lösungsmöglichkeit 3, nämlich PHP selbst zu kompilieren.

  • Alternativ gäbe es auch noch die Docker Variante. Das liefert dann automatisch die richtige PHP Version, inklusive aller Module, mit. Gerade in solchen Fällen bietet sich das gerade zu an, weil man zusäztlich die Möglichkeit hat, für jede Webapplikation eine andere PHP Version zu nutzen. Theoretisch geht das auch mit normalen Paketen, aber das ist in der Regel doch meist sehr umständlich.

  • Daß man mit dem aktuellen Debian-Release bei einer nicht mehr unterstützten PHP-Version landet und deshalb aktuelle Software, die PHP voraussetzt, nicht mehr nutzen kann, hätte ich eigentlich nicht für möglich gehalten.

    Debian verfolgt die Philosophie von Konservative Stable. D.H. keine Versionssprung in Major Versionen. Das ist also möglich und auch gut so.

    Wenn dir dass missfällt, hast du die falsche Distribution gewählt.


    Woher soll ich wissen,

    ob man dieser Software überhaupt trauen kann?
    ob darüber (Security-)Updates ausgeliefert werden?
    ob ich mir zukünftig damit irgendwelche (Kompatibilitäts-)Probleme einhandeln werde?
    ob es das Repository in einem Monat oder in einem Jahr überhaupt noch geben wird?

    Willkommen in der Welt der Open Source Software. Das trifft auf so ziemlich alle Repos zu, auch auf die offiziellen Repos.

    Das Repo verwende ich seit mehreren Jahren.


    https://www.patreon.com/oerdnj

    https://github.com/oerdnj/deb.sury.org

    https://twitter.com/debsuryorg


    Ich empfinde das als genügend vertrauenswürdig.



    Wenn ich PHP 7.2 aus diesem Repo installieren würde, müßten dann auch alle PHP-Module wie z.B. php-curl, php-gd, php-imagick, php-mbstring, php-mysql, php-zip, usw. aus diesem Repository kommen? Falls ja: Kann ich vorher irgendwie überprüfen, ob es überhaupt alle PHP-Module in diesem Repository gibt, die ich für meine Anwendungen (u.a. nextcloud, ttrss sowie ein Forum) benötige?

    Sury hat alle Extensions die du brauchst. Auch exotischere, die es so nicht in den offiziellen Betriebssystem Repos gibt / gab (z.B. php-mongodb)

  • Bisher war mein Verständnis das, daß es sich bei Debian um eine sehr verbreitete Server-Distribution handelt und deshalb eine gute Wahl zum Hosting von Web-Applikationen darstellt. Daß man mit dem aktuellen Debian-Release bei einer nicht mehr unterstützten PHP-Version landet und deshalb aktuelle Software, die PHP voraussetzt, nicht mehr nutzen kann, hätte ich eigentlich nicht für möglich gehalten.

    PHP-Upgrades machen oft Schwierigkeiten durch inkompatible Änderungen.

    Webapplikationen können lang leben und verlangen dann eher ältere als neuere PHP-Versionen.

    Deshalb

    Debian verfolgt die Philosophie von Konservative Stable. D.H. keine Versionssprung in Major Versionen. Das ist […] gut so.


    Auch (Security-)Updates gibt es wohl keine mehr für 7.0.

    Bei Debian schon. php7.0_7.0.33-0+deb9u3_changelog

  • Moin,


    wenn der Server eher für private Zwecke genutzt wird und nicht die Existenz dran hängt, würde ich heute schon auf Debian Buster updaten. Das macht schon einen sehr stabilen Eindruck. Ist schon seit 3 Monaten im Full-Freeze.

  • Bitte vergesst nicht, dass obwohl php7.0 out of service ist seitens Debian noch immer Sicherheits-Updates ausgeliefert werden sollten solange die Distribution bzw. Version supported wird.


    lg.


  • Welche Arten von Security-Lücken werden bei Debian denn gefixt? Alle oder nur die Remote-Code-Execution und High Critical? Wie weit gibt es Fixes für Bugs? Bei den kommerziellen Distributionen werden auch die Bugfixes zurückportiert und man kann jahrelang auf einer Minor-Version bleiben.


    Ausserdem: Debian zieht hier einfach die Minor-Version hoch. Das ist unschön. Wie man an deinem Link sehen kann, war hier vor kurzem noch 7.0.27 aktuell, jetzt wurde einfach auf 7.0.33 hochgezogen. Hier kann man sich leicht mal inkompatible Updates einfangen. Hier bleibt man also nicht wirklich auf einer fixen Version sondenr updatet schleichend und spontan. Spontan immer dann, wenn es mal 'nen Security-Update gibt.

    "Security is like an onion - the more you dig in the more you want to cry"

  • Bitte vergesst nicht, dass obwohl php7.0 out of service ist seitens Debian noch immer Sicherheits-Updates ausgeliefert werden sollten solange die Distribution bzw. Version supported wird.


    lg.

    Also zumindest in der Theorie. Wie das in der Praxis aussieht, ist eine andere Geschichte. Security Bugs müssen in der alten Version erst einmal erkannt werden und dann muss ein funktionierender(!) Backport erstellt werden. Bei kommerziellen Distributionen wie SUSE oder RHEL kann ich mir das noch einigermaßen vorstellen. Da sitzen Leute, die werden genau dafür bezahlt. Aber gerade bei einer Community Distribution wie Debian habe ich da ein paar Bedenken. Nichts gegen die Entwickler. Die machen einen tollen Job. Aber diese Backport Geschichte von Bugs aus neueren Versionen, die evtl. auch in alten Versionen vorhanden sein können und das entsprechenden selbst zu patchen, ist wahrlich kein schöner Job.

    Wenn die Entwickler einer Software sagen, diese Version ist EOL, sollte man das lieber auch so hinnehmen, unabhängig davon, was einem die Distribution verspricht. Mit einer Firma wie RedHat hat man zumindest noch einen Vertrag. Da könnte man zur Not noch jemanden vor Gericht zerren, wenn doch mal was passieren würde. Aber bei Debian ist das etwas anderes.

    Generell besser keine Software einsetzen, die EOL ist. Außer man hat einen Vertrag mit einer Firma, die einem Backports/Sicherheitsupgrades garantiert. Man wiegt sich nur in einer falschen Sicherheit.