Beiträge von derwunner

    @Sauerland: Das meine ich damit: software.opensuse.org:


    Das Package ist, bzw. die Pacakages php5 sind nur in Thumblweed als stable verfügbar. Ansonsten findet man in dem Main Repo nur PHP Version 5.5, was stark veraltet ist.


    Und super, herzlichen Dank, ich habe nun php7 mittels


    Bash
    zypper addlock *php7*

    als gesperrt gekennzeichnet. Ein kurzer Test mittels


    Bash
    zypper up


    zeigte mir dann auch das erwartete Ergebnis an.


    Vielen Dank an alle, Thema hat sich somit geklärt.


    Mit

    Bash
    zypper in paket --no-recommends

    kann ich auch ganz leicht die Recommondations abschalten. Gerade bei Paketen wie git & co. ist das ganz hilfreich. Da ich zum Beispiel nie produktiv SVN verwendet habe, brauche ich auch keinen SVN-zu-git-Konverter.



    MFG


    derwunner

    Für Firmen eignet sich auch RedHat oder SuSE Linux Enterprise besser, denn dafür sind die beiden Distros ja auch gemacht worden. Das gleiche kann man soviel ich weiß mit Ubuntu erreichen, wenn man Cannonical etwas regelmäßig zahlt. Außerdem brauchen auch Firmen jemanden, den sie verklagen können, wenn etwas nicht so läuft, wie es soll. Und das hast Du nunmal nur bei Linux Distributionen, bei denen ein Hersteller dahinter steht, der dem Kunden garantiert, dass es geht. Das ist jetzt auch nicht irgendwelches "Stammtisch-Gerede", sondern das weiß ich von jemanden, der im Linux Hochverfügbarkeits- und Hochsensibelfeld arbeitet (Finanz- und Bankingbranche).
    Nichts desto trotz, kann man Enterprise Linxu auch kostenlos haben. Wer das haben will, der ist mit CentOS gut bedient, das ist ein kostenloser RedHat Klon. Fedora stammt zwar auch aus dem Hause RedHat, ist aber eine eigenständige Distribution, die nicht immer alles von RedHat übernimmt. Nur eben das, was die bei RedHat angestellten Entwickler wollen. Schließlich ist ja Fedora dessen Freizeit-Baby.


    @Berechtigung Also eine Spam-Schleuder war mein mit Plesk konfigurierter Server ganz und gar nicht. Kostenpflichtiger Virenschutz und Firewal imbegriffen. Sicherheitskonzepte übernahm Plesk automatisch. Darunter neben Dr. Web AV, auch rkhunter weekly reports etc.. Spamfilterung und das ganze Zeug war auch leicht möglich.
    Das Bottleneck war dabei nur die Sache, wenn man mehrere openSource Projekt unterschiedlicher Programmiersprachen gleichzeitig auf dem Server betreiben wollte. Erstens mal bot Plesk nur recht eingeschränkte Möglichkeiten für Ruby (on Rails) an, und zum anderen lief das nie so wirklich mit den angebotenen Möglichkeiten, selbst bei einem kleinen 0815 Ruby Projekt spuckte Plesk nur Fehlermeldungen aus. Das war aber auch recht neu in Plesk, den Ruby Support gabs erst mit der damaligen aktuellen Version.
    Ja, außerdem musste man PHP als FastCGI Modul laufen lassen, weil das das Plesk Web Interface brauchte und solche unsinnigen Scherze.
    Aber ich sehe schon (wie auch in anderen Beiträgen), dass wir eine unterschiedliche Weltanschauung haben in Bezug auf Computer Themen. Aber wie es halt so ist, es führen mehrere Wege nach Rom. Niemand sagt, dass Dein oder mein Weg der Idealweg ist. Ein Forum ist ja nur als Hilfestellung zu verstehen, aus dem man sich dann selber seine Meinung bilden kann. Von daher, sehe ich das alles nicht so streng. Und ja, ich kann Deinen Standpunkt auch nachvollziehen, dass ein Hardcore Linuxer nichts von Klickibunti hält. Das war schon immer so, und wird wohl auch immer so bleiben. Leider erkennen aber genau diese Leute nicht, dass Automatismen viel detaillierte Handarbeit ersparen können. Diese Automatismen sind sogar mittlerweile so weit fortgeschritten, dass man diese auf die eigenen individuellen Bedürfnisse und hohen Ansprüchen anpassen kann, damit sie genau das tun, was sie sollen und nicht mehr. Also, ich kann nur sagen, lebt nicht mehr in der Vergangenheit und macht euch selbst das Leben nicht unnötig schwer, das dankt euch schließlich niemand. Wie mein Chef schon immer sagt: "Du musst auch mal Software aus den Augen aus Menschen sehen, nicht aus den eines Programmierers". Mit dem Motto im Hinterkopf lassen sich manche Sachverhalte einfacher lösen, als man manchmal denkt.

    @TuxSv748: Es geht dabei nicht nur um die Einsteigerfreundlichkeit. Wenn Du weißt was Du tust und Du arbeitest auch noch beruflich mit Linux, dann willst Du Dich nicht stundenlang mit irgendwelchen Konfigurationen herum ärgern. Da sind solche gut getesteten Skripte von der Community ein wahrer Segen. Denn im Geschäftssinne ist Zeit Geld. Und wenn man sich mehr auf die Kernaufgaben konzentrieren kann, anstatt irgendwelche organisatorischen Maßnahmen durchführen zu müssen, dann ist das wesentlich produktiver.
    Ich hatte lange Zeit Plesk auf meinen Ubuntu Server im Einsatz. War echt geil, einen E-Mailserver in 10 Minuten sich zusammen klicken zu können. Auch die anderen Spielereien, wie Datenbanken und Webserver wurden damit zum Kinderspiel. Nach einiger Zeit musste ich jedoch feststellen, dass Plesk nur den Standard-0815-Fall abdeckt. Was zwar den meisten Anwendern reichen würde, aber einem Poweruser reicht das eben nicht mehr aus. Tja, ich bin an dem Punkt angekommen, wo ich Gitlab installieren wollte, und mir Plesk wegen der Webserver Konfiguration einen Strich durch die Rechnung gemacht hatte, da Plesk selbst auf nicht definierten Subdomains den Webserver lauschen lässt und dieses Verhalten konnte man ums verrecken nicht abstellen. Also gab es nur zwei Möglichkeiten: eine 2. IP holen und es darüber laufen lassen, oder bei einer bleiben und Plesk löschen. Ich hatte letzere gewählt, zumal ich in absehbarer Zeit auch Jenkins als Build-Server gebraucht hätte. Ich meine, wo hätte das dann geendet? In 10 IP's?! Sorry, aber so groß ist mein Geldbeutel auch nicht...


    PS: Zu meinen obigen Beitrag noch als Ergänzung: Ich finde in Linux sollte es auch die Systemintegrität wie bei Mac geben, dass alles was in /bin und /sbin liegt nicht mal mehr vom root User überschrieben werden kann. Das kann man zwar mit rkhunter überprüfen, jedoch kann dann trotzdem noch jeder User die Systemkommandos überschrieben. Also so ein Tool in Linux wäre auch noch cool, zumal ja eh die meisten nachinstallierten Anwendungen ihre Kommandos bereits unter /usr/local ablegen. Wäre also kein großer Aufwand ein solche Tool einzuführen.

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

    Vielleicht ein Dateiberechtigungsproblem? Setze doch mal die Rechte auf 0777 für das Icon unter /usr/share/icons/myicons


    Du sagst, dass sobald Du es in den Arbeitsflächen-Ordner legst, dass es dann geht. Worauf verweist denn Dein Arbeitsflächen-Ordner? Ich vermute irgendwo unter /home/user, oder?

    Bei München stellen sich die Politiker auf stur, weil sie sich nicht umstellen wollen. Und München hat genug Geld, denen juckt das wirklich nicht, wie viel der Umstieg wieder kostet. Das ist leider so.

    Fazit: Ist egal was Du nimmst. Du mußt glücklich damit sein, mehr nicht. Aber ein Linux sollte es schon sein..... :smilie_pc_011:


    Hmm, prinzipiell gebe ich Dir recht. Wobei ich aber auch sagen muss, dass ich seit vier Monaten auf der Arbeit ein Mac Book verwenden muss. Unterscheidet sich kaum mehr zu Linux, ist ja schließlich auch ein FreeBSD drunter. Die GNU Utils hat es auch, der Unterschied fällt also fast nur noch bei der Dateisystem Struktur auf. Oh, und vorallem darin, dass es einfach läuft, im Gegensatz zu Linux. Ich war bisher immer der Meinung, dass Mac das Linux für faule Leute ist. Nun ja, ich fühle mich nach vier Monaten intensiver Erfahrung damit nur bestätigt. Was jetzt aber auch nicht heißt, dass ich mir privat einen Mac holen werde - ganz im Gegenteil ich bin eigentlich anerkannter Mac Nörgler / Hasser (unter anderem wegen der Tastatur - drei Tastendrücke gleichzeitig für ein ] und solche Scherze, untragbar für einen Programmierer; dem Adapter Geäffe und ein paar GUI Eigenheiten, die mir absolut nicht einleuchten).


    Ja, (K)Ubuntu kann schon schön sein, besonders weil es dafür tonnenweise Skripte gibt, die die Installation von manchen Programmen deutlich erleichtern. Ich spiele damit auf die Serverdienste Mailcow, dem automatisierten Game Server Installationsskript für HLDS bzw. SRCDS und openVZ an.
    Aber auch in Sachen PC Usuability gibt es ein paar solcher Nettigkeiten, die es für openSUSE nicht gibt. Das liegt aber schlicht und ergreifend daran, dass Ubuntu wesentlich beliebter ist, und sich deswegen viele Programmierer einen Dreck um RPM basierte Linux Distros scheren. Falls es sie dennoch interessiert, dann steht RedHat an erster Stelle, dann vielleicht noch Fedora und mit sehr viel unwahrscheinlichem Glück auch irgendwann mal openSUSE an 30. Stelle.
    Das ging mir schon oft so, dass ich gerne Dinge für openSUSE gehabt hätte, die es aber nur für *.deb basierte Distros gab. Siehe die oben erwähnten Beispiele. Auch die meisten Kompilieranleitungen für bekannte Cross-Plattform openSource Projekte beschränken sich meistens nur auf das Kompilieren unter Debian und Ubuntu. Ich weiß noch genau, was das vor ca. einem Jahr für ein Aufwand war, alle benötigten Softwarepakete für Mixxx zu sammeln unter openSUSE, nur um hinterher festzustellen, dass es doch nicht geht und es im Hersteller-Forum keine Hilfestellung gab. Nach insgesamt acht Stunden versuchen gab ich dann schließlich auf. Ich erhoffte mir von dem selbst Kompilieren bessere Soundkarten Latenz Zeiten, frei nach dem Gentoo Motto / Glauben.


    Ich bin schon lange auf der Suche nach einer Distro, die so beliebt ist wie Ubuntu, die jedoch RPM basiert ist, die ein YAST bietet und die vom Funktionsumfang her openSUSE ähnelt. Also quasi nimm die Benutzerfreundlichkeit von Ubuntu, die "Bleeding Edge" Software-Strategie von Fedora, die GUI Konfiguraitonsmöglichkeiten von openSUSE, ein besseres KDE 4 => et volài - die perfekte Distro wäre geboren :)

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

    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.