CentOS: neueres PHP + MariaDB installieren?

[HaZweiOh]

Hallo,

ein Server, der noch mit CentOS 6 läuft, bräuchte eine neuere PHP-Version und evt. auch eine neuere MySQL/MariaDB und phpMyAdmin.
Ein Update auf CentOS 7 möchte ich im Moment noch vermeiden, um Probleme durch weitere Änderungen zwischen CentOS 6 und 7 zu umgehen. In Sachen PHP würde das auch kaum was bringen. Es soll nur um PHP (und evt. MySQL) gehen. Habt Ihr Erfahrungen mit neueren PHP-Versionen für CentOS 6, aus anderen Repos? Geht sowas in der Regel gut oder sollte man die Finger davon lassen?
(dass die Kompatibilität mit den Applikationen dazu passen muss, ist natürlich klar)

 

[konkretor]

Lohnt der Aufwand noch Ende 2020 ist eh Schluss mit CentOS 6.

 

[HaZweiOh]

Ja, dann könnte ich neuere Software verwenden. Und der geringe Aufwand ist gerade der Vorteil gegenüber einem CentOS 7-Update, womit trotzdem nur PHP 5.4 zur Verfügung stünde. Dann hätte ich das gleiche Problem.

Die Frage ist nur, ob das öfter schief geht.

 

[bananajoe2k4]

Ufff, php 5.4 ist von 2012! Wenn du nicht auf so Geschnörksel wie Plesk/Onyx angewiesen bist, dann kann ich dir nur Archlinux als Server-Dristro wärmstens empfehlen. Ist zwar etwas Aufwand (einmalig) bei der Einrichtung/Umstellung, aber da Rolling-Release gibt es keine Distro-Upgrades mehr. Hab alle meine Server 2013 auf Arch umgestellt, weil ich es satt war immer mit 5-7 Jahre alter Software rumzugurken. Die topaktuellen Pakete möchte ich mittlerweile nicht mehr missen!

 

[snaxilian]

Naja, bei nem rolling release solltest aber auch nicht ewig warten zwischen Updates... Aber generell scheint dann Centos für dich die falsche Distribution zu sein, denn als Abkömmling von Red Hat hat es nun einmal lange Lebenszeiten und dementsprechend auch alte Versionen wobei Security Patches idR zurück portiert werden.

Du kannst natürlich auch anfrangen, mit fremden Repos zu arbeiten aber dass musst du den Maintainern des Repos vertrauen, dass dort kein Schindluder mit den Paketen veranstaltet wird. Vor einem Dist-Upgrade würde ich Fremdrepos aber immer deaktivieren.

Nächste Möglichkeit: Upgrade auf Centos 7 und du packst deine Applikationen in Docker-Container. Dort kannst dann je nach Anwendung bleeding edge Versionen nehmen oder was auch immer du gerade benötigst. So kannst zumindest einfach unterschiedliche Versionen auf dem selben Host betreiben, hast dafür dann natürlich Docker "am Bein".

 

[HaZweiOh]

Einen neue Distribution kommt im Moment nicht in Frage!
Das einfachste wäre halt ein aktuelles PHP?!
Die Erfahrungen im Netz klingen ja ganz positiv....

Kann das jemand bestätigen?

 

[bananajoe2k4]

Dann mach ein Backup und probiere es aus :-) Mehr als kaputt machen kannst es nicht, dann einfach Backup zurückspielen.

 

[snaxilian]

Fremd-Repos funktionieren meist, Betonung auf meist! Denn wenn da nicht nur PHP drin ist, musst auch sicherstellen, dass die anderen ggf. installierten Pakete nicht auch über das Fremd-Repo aktualisiert werden. Auch kann es bei Fremd-Repos Probleme geben bei späteren Dist-Upgrades, musst du ebenso beachten und zu guter Letzt eben musst dem oder den Maintainer(n) des Fremd-Repos so weit glauben und darauf hoffen, dass diese dir keinen Schund unterjubeln.

 

[andy_m4]

Du könntest Software Collections ( https://wiki.centos.org/SpecialInterestGroup/SCLo/CollectionsList ) verwenden. Sind letztlich zwar auch Dritt-Repositories aber immer noch am nächsten am Redhat-Umfeld.

Alternativ kann man versuchen ein aktuelles PHP natürlich auch selbst zu kompilieren und zu hoffen, das es keine größeren/problematischen Abhängigkeiten gibt. Man muss dann natürlich auch immer neu kompilieren, wenn ein Bugfix rauskommt.

 

[mensch183]

Installiere die aktuellen Versionenin einem Pfad, in dem du nicht mit den in Centos enthaltetenen Uraltversionen kollidieren kannst, selbst wenn was davon installiert ist. Alles nach /usr/local/blablub oder so. Damit kannst du dir nichts zerschießen. Falls die aktuellen Varianten von zum Bauen irgendwelche Libraries in neueren Verionen benötigen, als bei CentOS dabei sind, kommen die Libraries auch mit in den Pfad. Alles schön beisammen. Alles unabhängig von den CentOS-Versionen.

Wenn fremde Leute auf den Webserver zugreifen werden, würde ich auch Webserver und SSL-Bibliothek durch aktuelle Varianten ersetzen. Da hat sich vieles getan. Das Uraltzeug ist immer bischen peinlich.

 

[andy_m4]

Genau. Das wäre noch wichtig. Wenn man selbst kompiliert, dann möglichst immer nach /usr/local/

 

[snaxilian]

@mensch183 Es ist ein kleiner aber feiner Unterschied zwischen "uralter" Version, für die trotzdem Features und Bugfixe zurück portiert werden und "uralter" Software, wo dies nicht passiert. Man kann problemlos mit Centos 6 einen aktuellen Webserver mit TLS 1.2 und modernen Ciphers betreiben wobei es dann natürlich schon ein 6.9 oder 6.10 sein sollte.

 

[HaZweiOh]

Das CentOS 6 hat natürlich alle (zurückportierten) Patches. Selbst kompilieren kommt nicht in Frage, weil es jetzt und später keinen (Pflege-)Aufwand nach sich ziehen soll.

@andy_m4 : Vielen Dank für den Tipp mit den Software collections. Dort gibt es PHP 7.0 für CentOS 6, sehr interessant!

 

[mensch183]

Man kann problemlos mit Centos 6 einen aktuellen Webserver mit TLS 1.2 und modernen Ciphers betreiben wobei es dann natürlich schon ein 6.9 oder 6.10 sein sollte.

kA wie weit die Patcherei im Detail geht. TLS 1.2 ist ja nun auch nicht gerade der letzte Schrei sondern die mindestens zu nehmende Hürde, um überhaupt noch mitspielen zu dürfen.

disclaimer: Ich setze gedanklich Centos mit RHEL gleich. Vielleicht zu unrecht.
Bei RHEL wars es meiner Erinnerung nach sogar so, dass die in Sachen SSL nicht nur nicht aktuell waren, sondern gegenüber einer default-Konfiguration auch noch eingeschränkt. Waren nicht auf RHEL sämtliche EC-basierten Ciphers deaktiviert? Falls das mittlerweile anders ist oder Centos diesen Blödsinn sowieso nie nachgemacht hat - prima.

"Privat", also abseits des Upstream-Anbieters, hochgepatchte Altsoftware ist eben unschön, wenn man nicht nur in der Wolke des jeweiligen Vendors unterwegs ist. Es kostet einen Haufen Arbeit herauszufinden, was denn nun in der von Vendor X privat gepatchten Altversion Y tatsächlich drinsteckt.

Das eigentliche Thema des Threads scheint ja geklärt zu sein.

 

[andy_m4]

Ich setze gedanklich Centos mit RHEL gleich. Vielleicht zu unrecht.

Nee. Das ist schon richtig. CentOS als Solches baut Redhat Enterprise Linux nach. RHEL gibts halt nur gegen Kohle. CentOS ist quasi das kostenlose RHEL.

"Privat", also abseits des Upstream-Anbieters, hochgepatchte Altsoftware ist eben unschön

Sagen wir mal so: Es ist ein zweischneidiges Schwert.

 

[snaxilian]

Centos und RHEL sind binärkompatibel. Aber so ziemlich jede(!) Distribution macht Änderungen an Software. Sei es zurück portierte Patche oder Defaultsettings, die die Distributionsmaintainer für richtig erachten oder teilweise eigene abweichende Versionsnummern.
Ja, ein RHEL/Centos hat vielleicht keinen bleeding edge Anspruch sondern eher einen sicheren, stabilen und konservativen Weg und doch basiert z.B. das Standardimage für AWS EC2 Instanzen auf RHEL/Centos und nicht auf Arch oder Fedora oder Debian oder Ubuntu oder was auch immer. Ich wage mal zu behaupten, dass sich AWS etwas dabei gedacht hat.

Um beim Beispiel Ciphers zu bleiben: So ziemlich jede Distribution liefert aus Kompatibilitätsgründen idR alte/schwächere Ciphers aus egal ob es sich dabei um SSH oder TLS Webserver handelt oder wo auch immer man dies verwenden möchte. Da muss man dann einfach abwägen ob man nur state-of-the-Art Geräte rein lassen will oder ob einem z.B. auch die Kunden wichtig sind, die ein Win7 oder Android 4.x verwenden aber eben doch Umsatz generieren.
Im privaten Umfeld kann man das anders machen wenn man explizit weiß, dass alle zugreifenden User/Clients/Geräte nur moderne Ciphers unterstützen.

 

[mensch183]

Das von mir beschriebene Deaktivieren ganzer Cipher-Klassen, was RHEL macht(e?), hilft ganz sicher nicht, einen größeren Kundenkreis auf einen Webserver zu lassen. Redhat sah irgendwelche rechtlichen Gründe dafür, die der Rest der Welt nicht sah.

/edit:
Hier bzw. besser hier Fedora-Bugmeldungen, um zu zeigen was ich meine. RHEL hat(te?) die gleiche Verkrüppelung - auch in Zeiten als Centos6 rauskam. Die gesamte EC-Krypto war nicht nur in der Webserver-Konfig deaktivert sondern schon beim openssl-build rausgeflogen
... und wohl ab RHEL6.5 wieder reingepatcht ... nur ca. 6 Jahre nachdem der Rest der Welt damit arbeitete.

 

[Y-Chromosome]

wenn es Dir wirklich nur um PHP geht solltest Du Dir einmal REMI ansehen:
https://rpms.remirepo.net/

gibt einen wizard, der Dir genau sagt, was Du zu tun hast:
https://rpms.remirepo.net/wizard/

 

[konkretor]

Cool remirepo kannte ich noch nicht. Danke für den Link