PHP 5.6 richtig installieren

Hinweis: In dem Thema PHP 5.6 richtig installieren gibt es 16 Antworten auf 2 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Hallo Leute,


    ich hatte neulich versucht, auf meinen Server PHP 5.6 zu installieren über das Repo openSUSE Build Service Factory:PHP (oder so ähnlich, war auf jeden Fall ein Factory Repo, aus dem man PHP 5.6 beziehen konnte). Damit ich auch die richtigen Pakete bekam, hatte ich dem Factory die niedrigste Prio gegeben, also 90 in meinen Fall, während alle anderen noch auf dem Standard-Wert 99 waren. Das verlief alles noch soweit wie erwartet.


    Als ich dann ein paar Tage später zypper up ausgeführt hatte, ging der Ärger los. Er zeigte mir in der Update Vorschau über 500 Aktualisierungen, einen Architektur-Wechsel und einen neueren Kernel an. Nach dem besagten Update ging kein YAST, zypper und wget mehr. Letzendlich lag es daran, dass die erwähnten Core Kommandos neuer waren als anderen und versucht hatten, auf nicht existierende Funktionen in den Bibliotheken zurück zu greifen. Dass das nicht gehen kann, ist klar. Ich hatte dann das Repo wieder entfernt, libzypp und libproxy händisch per rpm wieder installiert, also quasi ein downgrade ausgeführt und dann mittels zypper dup wieder alles andere down gegradet. Danach lief das Trio wieder einwandfrei. Komisch, dabei wollte ich eigentlich nur eine aktuelle PHP 5 Version und bin davon ausgegangen, auch nur das aus dem Repo zu beziehen.


    Hat da jemand einen Vorschlag, wie man das besser machen könnte, damit es zukünftig nicht mehr zu den Problem kommt? Ich möchte es tunlichst vermeiden, PHP selbst kompilieren zu müssen. Schließlich ist es schon praktisch, dass man in openSUSE PHP Erweiterungen einfach nachinstallieren kann und die werden damit automatisch in der php.ini aktiviert. Diesen "kleinen Luxus" möchte ich nicht missen. Von daher müsste ich wohl wieder ein zusätzliches Repo einbinden.


    Ich habe openSUSE 42.2 Minimal in Verwendung vom Hetzner image. Installiert wurde das auch mittels des installimage Tools von Hetzner. Komisch finde ich ebenfalls, dass ich keine Datei /etc/release habe, sondern nur eine /etc/brand und in der stand "openSUSE 13.3" drin?!



    MFG


    derwunner

    Diese Signatur ist derzeit nicht verfügbar.

    Für den Inhalt des Beitrages 107359 haftet ausdrücklich der jeweilige Autor: derwunner

  • Was nun in deinem speziellen Falle besser ist, steht noch nicht fest. Ich halte es immer so. Brauch ich eine Software aus einem anderen Repo dann installiere ich diese und wenn sie läuft, deaktiviere ich umgehend das Installationsrepo. Hat bisher immer funktioniert.

  • Ok und wie funktioniert das dann bei einem Update? Nicht dass er dann anfängt PHP 5.6 auf PHP 5.5 wieder down zu graden beim zypper up.


    Vielleicht noch eine Randnotiz: Ich kann aktuell noch nicht auf PHP 7 umsteigen, weil ich ein größeres Projekt habe, das erst noch umfassend unter PHP 7 getestet werden muss. Prinzipiell sollte es schon klappen, da ich immer auf Ab- und Aufwärtskompatibilität achte, aber ganz sicher ist das nicht. Und da ich viel Wert auf hohe Software Qualität lege, werde ich wohl noch eine Zeit lang PHP 5.6 brauchen.

    Diese Signatur ist derzeit nicht verfügbar.

    Für den Inhalt des Beitrages 107364 haftet ausdrücklich der jeweilige Autor: derwunner

  • PHP und eine Debatte über Stabilität?
    Gelächter.
    Das ist ein vorsätzliches Sicherheitsloch.
    Sonst nichts.


    Ein Tumbleweed Repo in eine Leap Installation zu knallen, ist immer tödlich.
    Installiere dir den Krempel händisch, und trage den Unsinn wieder händisch in die ini ein.


    Dieses Argument beißt sich ziemlich heftig mit dem Wertlegen auf Stabilität.


    Einfach jedes PHP Modul vollautomatisch aktivieren zu lassen, ohne zu wissen, ob mal das überhaupt braucht, reißt noch mehr Sicherheitslöcher auf.

  • PHP und eine Debatte über Stabilität?
    Gelächter.
    Das ist ein vorsätzliches Sicherheitsloch.
    Sonst nichts


    Ich installiere keine PHP openSource Projekte von irgendwelchen Bastlern. Also Sicherheitslöcher aufgrund moderater bis schlechter PHP Programmierung sind bei mir ausgeschlossen. Außerdem prüfe ich auch jedes PHP openSource Projekt vorher, ob es meinen hohen Anforderungen entspricht. Tut es das nicht, ist die GitHub Seite schneller wieder zu, als sie offen war...


    Ein Tumbleweed Repo in eine Leap Installation zu knallen, ist immer tödlich.


    Installiere dir den Krempel händisch, und trage den Unsinn wieder händisch in die ini ein

    Ok, sorry, das wusste ich nicht. Aber PHP 5.6 ist schon seit mehr als drei Jahren als instabil gekennzeichnet. Wann wollen die das endlich als stable markieren?! Das weiß ich nämlich, weil in meiner virutellen Entwicklungsumgebung läuft das nämlich seit Jahren einwandfrei, auch mit regelmäßigen Updates. Warum das jetzt hier auf dem Server anders sein soll, ist mir auch nicht ganz klar. War ja schon öfters so, wenn man auf Linux was neu macht, was man vorher 10 mal genauso gemacht hatte, dass es dann plötzlich beim 10. Mal nicht mehr ging. Wie auch immer, mir kam beim Update schon die Frage nach dem Architekturwechsel spanisch vor. Naja, in Zukunft lasse ich lieber die Finger von Thumbleweed. Ich dachte ich wäre schon fortgeschritten genug, dass ich kleinere Bug Ausreiser im Griff hätte. Aber zum "Auskennen" gehört anscheinend mehr als einfach einen Apachen mit MySQL bedienen zu können, sowie die GNU Utils zu kennen und zu beherrschen.

    Dieses Argument beißt sich ziemlich heftig mit dem Wertlegen auf Stabilität.

    Ich meinte jetzt rein auf meine Projekte bezogen, nicht im Allgemeinen. Sorry, wenn das falsch rüber kam.

    Einfach jedes PHP Modul vollautomatisch aktivieren zu lassen, ohne zu wissen, ob mal das überhaupt braucht, reißt noch mehr Sicherheitslöcher auf.

    In jeder Software gibt es Sicherheitslöcher, in dem Buch "Cyberwar" schreibt der Autor sogar: "Je komplexer eine Software, desto mehr Angriffsvektoren". Niemand ist perfekt und keine Software Bug-frei. Also deine Aussage stimmt so nicht, wenn Du darauf anspielen willst, dass PHP Erweiterungen unsicher seien. Außerdem ich brauche sie wirklich, denn wer kommt denn heute noch ohne intl, mbstring und gd aus?
    Des Weiteren weiß ich genau, was im Hintegrund geschieht. Musste den Mist schon oft genug unter Mac OS X selbst kompilieren, bzw. mich mit Homebrew und dem Käse rumschlagen. Also ist für mich der Automatismus reine Bequemlichkeit, der mir etwas meiner wertvollen Zeit erspart.



    Ok, zurück zum Thema: @Sauerland Danke, werde ich morgen mal in Ruhe probieren. Mit Hektik und schnell etwas machen kommt man bekanntlich auf dem Server nicht weit...

    Diese Signatur ist derzeit nicht verfügbar.

    2 Mal editiert, zuletzt von derwunner ()

    Für den Inhalt des Beitrages 107376 haftet ausdrücklich der jeweilige Autor: derwunner

  • Die Frage ist falsch.
    Tumbleweed ist ein Rolling Release.
    Leap nicht.


    Wenn du so willst, dann nenne Tumbleweed constant unstable
    Leap und Tumbleweed sind zwei völlig verschiedene Paar Stiefel.



    Ich komme ganz ohne PHP aus.
    Es läuft nginx mit uwsgi,
    und dahinter habe ich ein Framework namens web2py.
    (Damit kann ich natürlich auch direkt Pythonscripte ausführen, oder sonst so manches Ding auch in völlig anderen Sprachen einfach implementieren.)


    Ganz andere Hausnummer.
    Das nennt sich moderne Webprogrammierung.


    PHP braucht man nur, weil viele glauben, man brauche es.
    Es ist krank per definitionem.


    Ich meine das schon sehr fundamentalistisch.
    Nicht nur irgendwelche Module.
    Ich muss z.B. nicht auf das Model- View- Controller beim programmieren achten.
    Es ist implizit und man kann gar nicht ohne. Damit sind viele Angriffe gar nicht erst möglich.
    PHP wird auf meinen Servern nicht mal installiert.


    Fehlentwicklungen, wie PHP, asp oder jsp können andere Server verhunzen, meine nicht.

  • Fehlentwicklungen, wie PHP, asp oder jsp können andere Server verhunzen, meine nicht.


    Man kanns auch übertreiben. Sinnvoller wäre es PHP und Java besser zu machen.

    we are motörhead and we play rock and roll

    Für den Inhalt des Beitrages 107402 haftet ausdrücklich der jeweilige Autor: raptor49

  • Die Frage ist falsch.
    Tumbleweed ist ein Rolling Release.
    Leap nicht.

    Naja, aber warum ist dann das Paket php 5.6 aus dem offiziellen Repo immer noch als instabil markiert? Bekommen die es nicht gebacken in fünf Jahren oder so mal ein Paket zu testen?!



    Aha. Python finde ich eine Krankheit, aber das ist Geschmackssache. Bei Ruby habe ich Blut und Wasser gekotzt, ich hatte es nicht fertig gebracht openproject oder Gitlab zu installieren, nach jeweils mehr als acht Stunden Arbeit daran. Von daher ist für mich PHP die deutlich einfachere Lösung. Außerdem kann ich ein über mehrere Jahre entwickeltes Projekt nicht einfach so übern Haufen werfen. PHP ist und bleibt nach wie vor der Standard der Dinge in der Webentwicklung. Zugegeben, NodeJS holt zwar rasant auf, aber bis NodeJS PHP ablösen wird als Spitzenreiter, wird noch eine Weile vergehen.



    Zurück zum Thema: Super @Sauerland hat wunderbar geklappt: Repo hinzufügen, Prio auf 90 setzen und ein kleines zypper in php5 [...] taten den Job. Eine kleine Sache noch: Wie kann ich PHP7 blacklisten? Zypper gab mir nämlich jetzt folgendes aus:



    Google hatte bei "zypper blacklist php7" nicht so viel sinnvolle Ergebnisse ausgespuckt, sonst würde ich jetzt nicht fragen. Ich wusste, das ging mal irgendwie...

    Diese Signatur ist derzeit nicht verfügbar.

    Für den Inhalt des Beitrages 107405 haftet ausdrücklich der jeweilige Autor: derwunner

  • Code
    zypper --help

    Und ziemlich am Ende.......


    Paketsperren.......


    Oder in der Softwareverwaltung ein Rechtsklick auf das kleine Kästchen vor php7.......


    Und die recommends abstellen:
    Abhängigkeiten------ Haken raus bei "empfohlenen Pakete installieren"

    Für den Inhalt des Beitrages 107409 haftet ausdrücklich der jeweilige Autor: Sauerland