Moin!
Nochmal ich. Das php aus dem default ist mit 5.4.16 ja schon recht betagt. Eine Websoftware verlangt jetzt ein neuere Version; also dachte ich, warum nicht gleich auf Version 7 hochziehen.
Etwas $suchmaschine gab die schöne Seite https://wiki.centos.org/HowTos/php7
Ok, gilt für CentOS 7.4 aber ich hatte gehofft, da es bei meinem neueren (7.5) ebenso läuft.
Ein Webserver habe ich schon installiert und eingerichtet; zudem entferne ich grundsätzlich das -y bei yum's. (Kleiner Schisser, ich.)
# yum install rh-php70 rh-php70-php rh-php70-php-fpm
So, was sehen meine entzündeten Augen:
Das Scheißerlein will: httpd24-httpd httpd24-httpd-tools httpd24-libnghttp2 httpd24-runtime
haben. Ok, nun bin ich mir zu 70% sicher, dass sich das httpd24-httpd-Paket nur unter /opt/rh/httpd24 breit macht. Die Frage: Muss das sein?, kann ich mir selbst beantworten ;-)
Hat damit jemand schon mal Erfahrung gesammelt mit einem gleichzeitig installierten Paket httpd24-http und httpd? Stört das? Sollte man lieber auf httpd24-http umsteigen? Warum wird in der o.g. Webseite aber httpd noch mitinstalliert? Ist das wumpe, solange man httpd24-httpd.service nicht startet/enabled?
Soo viele Fragen und das bei einem schon fast fertig eingerichteten System. Gnaaaa.
VG Rainer
On 19.10.18 16:52, Rainer.Rose@HannIT.de wrote:
# yum install rh-php70 rh-php70-php rh-php70-php-fpm
httpd24-httpd httpd24-httpd-tools httpd24-libnghttp2 httpd24-runtime
haben. Ok, nun bin ich mir zu 70% sicher, dass sich das httpd24-httpd-Paket nur unter /opt/rh/httpd24 breit macht. Die Frage: Muss das sein?, kann ich mir selbst beantworten ;-)
Die Frage beantwortet Dir das eben erwähnte Tool mit
repoquery --requires rh-php70-php
Hat damit jemand schon mal Erfahrung gesammelt mit einem gleichzeitig installierten Paket httpd24-http und httpd?
Wenn Du httpd24-http installiert hast, kannst Du Dir m.W. httpd schenken.
Viele Grüße Ulf
Hallo Rainer,
schau mal hier, das habe ich mal für mich erstellt: https://dokuwiki.tachtler.net/doku.php?id=tachtler:centos_7_-_sclo_software_...
Und ja, Du kannst httpd und httpd24-httpd auf einem Server installieren und beide installationen kommen sich nicht in die Quere, da alles was aus den SCLO Repos kommt sich unter /opt bzw. /etc/opt installiert.
Grüße Klaus.
Moin!
Nochmal ich. Das php aus dem default ist mit 5.4.16 ja schon recht betagt. Eine Websoftware verlangt jetzt ein neuere Version; also dachte ich, warum nicht gleich auf Version 7 hochziehen.
Etwas $suchmaschine gab die schöne Seite https://wiki.centos.org/HowTos/php7
Ok, gilt für CentOS 7.4 aber ich hatte gehofft, da es bei meinem neueren (7.5) ebenso läuft.
Ein Webserver habe ich schon installiert und eingerichtet; zudem entferne ich grundsätzlich das -y bei yum's. (Kleiner Schisser, ich.)
# yum install rh-php70 rh-php70-php rh-php70-php-fpm
So, was sehen meine entzündeten Augen:
Das Scheißerlein will: httpd24-httpd httpd24-httpd-tools httpd24-libnghttp2 httpd24-runtime
haben. Ok, nun bin ich mir zu 70% sicher, dass sich das httpd24-httpd-Paket nur unter /opt/rh/httpd24 breit macht. Die Frage: Muss das sein?, kann ich mir selbst beantworten ;-)
Hat damit jemand schon mal Erfahrung gesammelt mit einem gleichzeitig installierten Paket httpd24-http und httpd? Stört das? Sollte man lieber auf httpd24-http umsteigen? Warum wird in der o.g. Webseite aber httpd noch mitinstalliert? Ist das wumpe, solange man httpd24-httpd.service nicht startet/enabled?
Soo viele Fragen und das bei einem schon fast fertig eingerichteten System. Gnaaaa.
VG Rainer
Bei PHP 7.x kann man statt mod_php auch php-fpm verwenden.
Wir machen das bei uns so, dass wir centos-release-scl und dann die Collection "rh-php71" installieren. Wenn man dabei das Paket rh-php71-php weglässt, zieht man sich auch keinen httpd24 hinterher. Installieren möchte man rh-php71-php-fpm und rh-php71-php-cli.
Nachteil ist zugegebenermaßen, dass man sich mit PHP-FPM auseinandersetzen muss, aber dafür rennt dann PHP schön getrennt vom Webserver. Wir konnten bisher auch noch keine Performance-Nachteile gegenüber mod_php feststellen.
Falls das für dich relevant ist: man kann mit ein paar Skripten und einem systemd-Template dafür sorgen, dass pro VirtualHost eine Instanz von PHP-FPM unter einer eigenen Nutzerkennung (statt "apache") läuft. Das funktioniert sogar mit angeschaltetem SELinux und PHP-FPM im httpd_t-Kontext.
Viele Grüße, Andreas
Am Freitag, den 19.10.2018, 14:52 +0000 schrieb Rainer.Rose@HannIT.de:
Moin!
Nochmal ich. Das php aus dem default ist mit 5.4.16 ja schon recht betagt. Eine Websoftware verlangt jetzt ein neuere Version; also dachte ich, warum nicht gleich auf Version 7 hochziehen.
Etwas $suchmaschine gab die schöne Seite https://wiki.centos.org/HowTos/php7
Ok, gilt für CentOS 7.4 aber ich hatte gehofft, da es bei meinem neueren (7.5) ebenso läuft.
Ein Webserver habe ich schon installiert und eingerichtet; zudem entferne ich grundsätzlich das -y bei yum's. (Kleiner Schisser, ich.)
# yum install rh-php70 rh-php70-php rh-php70-php-fpm
So, was sehen meine entzündeten Augen:
Das Scheißerlein will: httpd24-httpd httpd24-httpd-tools httpd24-libnghttp2 httpd24-runtime
haben. Ok, nun bin ich mir zu 70% sicher, dass sich das httpd24- httpd-Paket nur unter /opt/rh/httpd24 breit macht. Die Frage: Muss das sein?, kann ich mir selbst beantworten ;-)
Hat damit jemand schon mal Erfahrung gesammelt mit einem gleichzeitig installierten Paket httpd24-http und httpd? Stört das? Sollte man lieber auf httpd24-http umsteigen? Warum wird in der o.g. Webseite aber httpd noch mitinstalliert? Ist das wumpe, solange man httpd24-httpd.service nicht startet/enabled?
Soo viele Fragen und das bei einem schon fast fertig eingerichteten System. Gnaaaa.
VG Rainer
Hallo an alle!
Vielen Dank erst einmal für die zahlreichen, fundierten Rückmeldungen. Das hat mir alles sehr weitergeholfen. Ich lüpfe meinen (nicht vorhandenen) Hut. Ich will die Diskussion nicht zum Sterben bringen; bisher finde ich sie nämlich sehr interessant. Bitte gerne weitermachen. ;-) Als kurzes alive-Paket hier mein kurzer Zwischenstand:
Wir machen das bei uns so, dass wir centos-release-scl und dann die Collection "rh-php71" installieren. Wenn man dabei das Paket rh-php71-php weglässt, zieht man sich auch keinen httpd24 hinterher. Installieren
Heureka! Das war ja mal wieder einfach(tm).
Nachteil ist zugegebenermaßen, dass man sich mit PHP-FPM auseinandersetzen muss,
Das _klang_ auf der wiki-Seite[1] ja erstmal relativ harmlos. Ich habe mir mal eine Test-VM aufgesetzt, um erstmal rumzuspielen. Habe dann von der genannten wiki-seite [1] s/70/71/g also nur yum install rh-php71 rh-php71-php-fpm
und es gab weniger Abhängigkeiten. :-) Ein phpinfo() sah da auf den ersten Blick recht vielversprechend auf. Mal gucken, was passiert, wenn ich jetzt die anderen php-Module nachinstalliere. GD brauche ich noch, das habe ich schon gesehen; ist aber auch vorhanden. Bei den anderen Modulen muss ich jetzt nochmal die Install-Doku der $webanwendung durchforsten. Mal gucken, was da so an Überraschungen kommt.
Falls das für dich relevant ist: man kann mit ein paar Skripten und einem systemd-Template dafür sorgen, dass pro VirtualHost eine Instanz von PHP-FPM unter einer eigenen Nutzerkennung (statt "apache") läuft.
Oh! Das hört sich interessant an. Muss ich mir mal angucken, wenn ich mal Zeit habe (also nie). Oder hast Du da was für zum Abgucken oder gute URL-Empfehlungen.
Das funktioniert sogar mit angeschaltetem SELinux und PHP-FPM im httpd_t-Kontext.
Bei SE bin ich noch recht blank. Die ersten Sachen laufen, ich bin mir aber sicher, dass ich noch nicht alles durchdrungen habe (vielleicht die oberste Schicht). Eine Bilderbuch-Konfig habe ich da bestimmt nicher sicht zusammengeschustert. Gerade bei diesen SE-Typen wird bei mir das Eis recht schnell dünn. Naja, guck ich mir auch nochmal genauer an, wenn ich mal Zeit habe (tm).
VG Rainer
N'Abend,
On 10/19/2018 04:52 PM, Rainer.Rose@HannIT.de wrote:
Moin!
Nochmal ich.
Das php aus dem default ist mit 5.4.16 ja schon recht betagt. Eine Websoftware verlangt jetzt ein neuere Version; also dachte ich, warum nicht gleich auf Version 7 hochziehen.
ja, /das/ Problem kenne ich.
[...]
Das Scheißerlein will:
httpd24-httpd httpd24-httpd-tools httpd24-libnghttp2 httpd24-runtime
haben. Ok, nun bin ich mir zu 70% sicher, dass sich das httpd24-httpd-Paket nur unter /opt/rh/httpd24 breit macht.
Die Frage: Muss das sein?, kann ich mir selbst beantworten ;-) [...] Hat damit jemand schon mal Erfahrung gesammelt mit einem gleichzeitig installierten Paket httpd24-http und httpd?
Stört das? Sollte man lieber auf httpd24-http umsteigen? Warum wird in der o.g. Webseite aber httpd noch mitinstalliert?
Ist das wumpe, solange man httpd24-httpd.service nicht startet/enabled?
Grundsaetzlich finde ich das Arbeiten mit den Software Collections (ob RH oder Community) eine PITA. Schon allein die Pfade zu den jeweiligen Konfigurationsdateien und die ueberlangen Namen der Dienste treiben mich beim Tippen in den Wahnsinn. Ganz zu schweigen von Abhaengigkeitsproblemen wie Du sie beschreibst. Ich verwende deshalb seit Kurzem in solchen Faellen das IUS Repo (https://ius.io/), welches genau PHP7.x & Co. vorhaelt und mit den regulaeren httpd-Paketen von CentOS/RHEL zusammenspielt. Die Software-Collections habe ich jetzt von allen Servern herausgeschmissen.
Aber Achtung: Unbedingt vor Gebrauch https://ius.io/Usage/ lesen.
Soo viele Fragen und das bei einem schon fast fertig eingerichteten System. Gnaaaa.
War bei mir auch so. Dann SCLO raus, IUS rein, PHP7 installiert und schon hat alles (wieder) funktioniert. <30 Minuten Arbeit.
Gruss frank
VG Rainer
Habedieehre!
Am 21.10.2018 um 22:01 schrieb Frank Thommen:
Grundsaetzlich finde ich das Arbeiten mit den Software Collections (ob RH oder Community) eine PITA.
FULLACK - vor allem was diese special interest group bzw. die prereleases anbelangt. Ich nehme da mittlerweilen großen Abstand.
Schon allein die Pfade zu den jeweiligen Konfigurationsdateien ... Ganz zu schweigen von Abhaengigkeitsproblemen wie Du sie beschreibst.
Oh ja, da greife ich doch lieber auf das nachfogend benannte IUS-Repo zurück. Da kann man ganz ohne große Umstellung die aktuellen Pakete Nutzen und bekommt auch stets aktuelle Pakete geliefert. Wenn ich da mal die Updatezyklen von IUS und der SIG bei verschiedenen Installationen vergleiche gibt es doch da sehr große Unterschiede.
Ich verwende deshalb seit Kurzem in solchen Faellen das IUS Repo (https://ius.io/),
Jepp, habe hier bei einer Installations-/Kundenumgebung seit langer Zeit im Einsatz und möchte es nicht missen. :)
War bei mir auch so. Dann SCLO raus, IUS rein, PHP7 installiert und schon hat alles (wieder) funktioniert. <30 Minuten Arbeit.
Kommt mir sehr bekannt vor, nur der Wechsle z.B. von PHP1.1 auf 7.2 steht bei einer Kundeninstallation noch aus.
Servus Django
Moin,
Am Sonntag, den 21.10.2018, 22:01 +0200 schrieb Frank Thommen:
N'Abend,
On 10/19/2018 04:52 PM, Rainer.Rose@HannIT.de wrote:
Moin!
Nochmal ich.
Das php aus dem default ist mit 5.4.16 ja schon recht betagt. Eine Websoftware verlangt jetzt ein neuere Version; also dachte ich, warum nicht gleich auf Version 7 hochziehen.
ja, /das/ Problem kenne ich.
[...]
Das Scheißerlein will:
httpd24-httpd httpd24-httpd-tools httpd24-libnghttp2 httpd24-runtime
haben. Ok, nun bin ich mir zu 70% sicher, dass sich das httpd24-httpd-Paket nur unter /opt/rh/httpd24 breit macht.
Die Frage: Muss das sein?, kann ich mir selbst beantworten ;-) [...] Hat damit jemand schon mal Erfahrung gesammelt mit einem gleichzeitig installierten Paket httpd24-http und httpd?
Stört das? Sollte man lieber auf httpd24-http umsteigen? Warum wird in der o.g. Webseite aber httpd noch mitinstalliert?
Ist das wumpe, solange man httpd24-httpd.service nicht startet/enabled?
Grundsaetzlich finde ich das Arbeiten mit den Software Collections (ob RH oder Community) eine PITA. Schon allein die Pfade zu den jeweiligen Konfigurationsdateien und die ueberlangen Namen der Dienste treiben mich beim Tippen in den Wahnsinn. Ganz zu schweigen von Abhaengigkeitsproblemen wie Du sie beschreibst. Ich verwende deshalb seit Kurzem in solchen Faellen das IUS Repo (https://ius.io/), welches genau PHP7.x & Co. vorhaelt und mit den regulaeren httpd-Paketen von CentOS/RHEL zusammenspielt. Die Software-Collections habe ich jetzt von allen Servern herausgeschmissen.
Ich bin selbst wegen PHP oder Python von IUS auf SCL umgestiegen. Mein Umstieg ist auch relativ frisch geswesen.
Ich gebe meinen Vorrednern recht, was die langen Pfade von SCL angeht: Die können einem wirklich auf den Keks gehen. Ebenso habe ich dann und mal Probleme eine SCL umgebung flexibel (z.B. in Cron-jobs) zu laden - ein Großteil meiner Skripte ist in Pyhon>=3.5 geschrieben weshalb extra Arbeiten notwendig waren.
Auf der anderen Seite war für mich das Update von PHP 7.0 auf 7.1 mit SCL einfacher als bei einem Server auf dem ich noch IUS verwendet hatte.
Als Bonus bin ich mit SCL noch in der Lage eine alte PHP5 Applikation mit PHP5/httpd zu betreiben während ich moderne Applikationen unter PHP7.1/httpd24-httpd betreibe. Ich verwende übrigens inzwischen httpd24-httpd als Frontend und httpd nur noch auf localhost.
Vermutlich haben beide Techniken daher ihre Vor- bzw. Nachteile. Ich möchte IUS für die Zukunft nicht ausschließen bin aber derzeit ganz zufrieden mit SCL was die Pflege angeht.
Für mich ein wichtiger Punkt ist auch die Frage der Pflege. Mein letzter Stand ist, dass SCL von CentOS Entwicklern mit gepflegt wird — wenn auch inoffiziell — wärend IUS im wesentlichen von *einer* Person gepflegt und von Rackspace gesponsored wird.
Grüße, Theo
Hallo,
Ich verwende deshalb seit sehr lange Zeit erfolgreich https://webtatic.com/packages/php71/ auf unserem Server (Webserver). Hatte ich noch nie Probleme damit. Selbst der Upgrade von 5 auf 7 oder 7.1 gestaltet sich damit sehr angenehm.
LG Michael
-----Ursprüngliche Nachricht----- Von: CentOS-de centos-de-bounces@centos.org Im Auftrag von Theodor van Nahl Gesendet: Montag, 22. Oktober 2018 14:52 An: centos-de@centos.org Betreff: Re: [CentOS-de] PHP 7.x auf CentOS 7.5
Moin,
Am Sonntag, den 21.10.2018, 22:01 +0200 schrieb Frank Thommen:
N'Abend,
On 10/19/2018 04:52 PM, Rainer.Rose@HannIT.de wrote:
Moin!
Nochmal ich.
Das php aus dem default ist mit 5.4.16 ja schon recht betagt. Eine Websoftware verlangt jetzt ein neuere Version; also dachte ich, warum nicht gleich auf Version 7 hochziehen.
ja, /das/ Problem kenne ich.
[...]
Das Scheißerlein will:
httpd24-httpd httpd24-httpd-tools httpd24-libnghttp2 httpd24-runtime
haben. Ok, nun bin ich mir zu 70% sicher, dass sich das httpd24-httpd-Paket nur unter /opt/rh/httpd24 breit macht.
Die Frage: Muss das sein?, kann ich mir selbst beantworten ;-) [...] Hat damit jemand schon mal Erfahrung gesammelt mit einem gleichzeitig installierten Paket httpd24-http und httpd?
Stört das? Sollte man lieber auf httpd24-http umsteigen? Warum wird in der o.g. Webseite aber httpd noch mitinstalliert?
Ist das wumpe, solange man httpd24-httpd.service nicht startet/enabled?
Grundsaetzlich finde ich das Arbeiten mit den Software Collections (ob RH oder Community) eine PITA. Schon allein die Pfade zu den jeweiligen Konfigurationsdateien und die ueberlangen Namen der Dienste treiben mich beim Tippen in den Wahnsinn. Ganz zu schweigen von Abhaengigkeitsproblemen wie Du sie beschreibst. Ich verwende deshalb seit Kurzem in solchen Faellen das IUS Repo
(https://urldefense.proofpoint.com/v2/url?u=https- 3A__ius.io_&d=DwIGaQ&c=SgupRstEQHpxMBBZGflc53FptCkuYd- P8O27DFHVMzE&r=hBU6Flp6EJQRgGYBpxH94PPPVranAiYEAcPuJO3wNyjVYN UvOVG47A01iCR5BbEx&m=sNDDU8g1CSCX6u1bV0lEfWeK62BZxZBzEaz7EcBZf ho&s=5WY3fMdbovtDms8yXOFbaBtmPL6YlZM-6tcShrXHzAg&e=),
welches genau PHP7.x & Co. vorhaelt und mit den regulaeren httpd-Paketen von CentOS/RHEL zusammenspielt. Die Software-Collections habe ich jetzt von allen Servern herausgeschmissen.
Ich bin selbst wegen PHP oder Python von IUS auf SCL umgestiegen. Mein Umstieg ist auch relativ frisch geswesen.
Ich gebe meinen Vorrednern recht, was die langen Pfade von SCL angeht: Die können einem wirklich auf den Keks gehen. Ebenso habe ich dann und mal Probleme eine SCL umgebung flexibel (z.B. in Cron-jobs) zu laden - ein Großteil meiner Skripte ist in Pyhon>=3.5 geschrieben weshalb extra Arbeiten notwendig waren.
Auf der anderen Seite war für mich das Update von PHP 7.0 auf 7.1 mit SCL einfacher als bei einem Server auf dem ich noch IUS verwendet hatte.
Als Bonus bin ich mit SCL noch in der Lage eine alte PHP5 Applikation mit PHP5/httpd zu betreiben während ich moderne Applikationen unter PHP7.1/httpd24-httpd betreibe. Ich verwende übrigens inzwischen httpd24-httpd als Frontend und httpd nur noch auf localhost.
Vermutlich haben beide Techniken daher ihre Vor- bzw. Nachteile. Ich möchte IUS für die Zukunft nicht ausschließen bin aber derzeit ganz zufrieden mit SCL was die Pflege angeht.
Für mich ein wichtiger Punkt ist auch die Frage der Pflege. Mein letzter Stand ist, dass SCL von CentOS Entwicklern mit gepflegt wird — wenn auch inoffiziell — wärend IUS im wesentlichen von *einer* Person gepflegt und von Rackspace gesponsored wird.
Grüße, Theo
-- _______________________________________________ CentOS-de mailing list CentOS-de@centos.org https://urldefense.proofpoint.com/v2/url?u=https- 3A__lists.centos.org_mailman_listinfo_centos- 2Dde&d=DwIGaQ&c=SgupRstEQHpxMBBZGflc53FptCkuYd- P8O27DFHVMzE&r=hBU6Flp6EJQRgGYBpxH94PPPVranAiYEAcPuJO3wNyjVYN UvOVG47A01iCR5BbEx&m=sNDDU8g1CSCX6u1bV0lEfWeK62BZxZBzEaz7EcBZf ho&s=stgINWZXaSU09VQREfbPpvV0AxkjxQ5nPfIVrfusQxI&e=
Datenschutzerklärunghttps://www.wko.at/service/datenschutzerklaerung.html
-
Andreas Rogge -
Django [BOfH] -
Frank Thommen -
Klaus Tachtler -
Michael.Goldfinger＠inhouse.wko.at -
Rainer.Rose＠HannIT.de -
Theodor van Nahl -
Ulf Volmer