php7 im Apache aktivieren

[Klaus1]

Hallo,

ich versuche verzweifelt im Apache PHP7 zu aktivieren. Vorher war PHP5 installiert und aktiviert. PHP5 habe ich zunöchst mittels

zypper remove php5 

heruntergeworfen.

Danach PHP7 entsprechend mit installiert:

zypper in php7 php7-mysql apache2-mod_php7

und aktiviert:

a2enmod php7
service apache2 restart

Im conf.d-Verzeichnis wurde der SetHandler gesetzt:

<IfModule mod_php7.c>
       <FilesMatch \.php$>
           SetHandler application/x-httpd-php
       </FilesMatch>
        DirectoryIndex index.php
</IfModule>

Die conf-Dateien werden auch in der default-server.conf geladen

IncludeOptional /etc/apache2/conf.d/*.conf

Das php-Modul wurde geladen:

apachectl -t -D DUMP_MODULES

...
php7_module (shared)
...

Dennoch werden mir php-Dateien zum Download angeboten, anstatt dass die vom PHP interpretiert werden.

Hat noch jemand eine Idee, was ich falsch gemacht oder vergessen haben könnte?

LG Klaus

[Indianerversteher]

Hat noch jemand eine Idee, was ich falsch gemacht oder vergessen haben könnte?

Lösch mal den Cache des Browsers und versuch es nochmal. Alternativ liefert wget -d --delete-after URL Dir die wirklich abgerufenen und gesendeten Header. Browser sind für solche Tests 2. Wahl, es sei denn man hat die Entwicklerwerkzeuge (Hier: Netzwerkanalyse) aktiviert und in diesen den Cache deaktiviert.

Dennoch werden mir php-Dateien zum Download angeboten, anstatt dass die vom PHP interpretiert werden.

Es kann sogar sein, dass die PHP-Skripte zwar serverseitig verarbeitet werden, dass aber aus anderen Gründen ein falscher Header für den Content-Typ gesetzt wird. Sieh Dir das Ergebnis genau an.

[Klaus1]

Lösch mal den Cache des Browsers und versuch es nochmal.

Das sollte theoretisch mit einem Shift-Reload getan sein oder?

Alternativ liefert wget -d --delete-after URL Dir die wirklich abgerufenen und gesendeten Header.

Der wget liefert:

---request begin---
GET /page/index.php HTTP/1.1
User-Agent: Wget/1.14 (linux-gnu)
Accept: */*
Host: mydomain.net
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 200 OK
Date: Fri, 05 Jul 2019 12:43:29 GMT
Server: Apache
X-Powered-By: PHP/7.0.7
Content-Length: 7266
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8

---response end---

Ich würde vermuten, dass es nicht an den Seiten liegen kann, die ja mit PHP5 noch funktioniert haben. Es sei denn, dass mit PHP7 irgendeine mir unbekannte Restriktion auftritt, die es mit PHP5 noch nicht gab.

LG Klaus

[Indianerversteher]

X-Powered-By: PHP/7.0.7
Content-Type: text/html; charset=UTF-8

Das sieht, abgesehen vom veraltetem PHP 7.0, sehr gut aus und entspricht genau den Erwartungen.

Jetzt baust Du eine test.php:

<h1>Dieser Server auf <?=$_SERVER["HOSTNAME"] ?>funktioniert mit PHP <?=phpversion() ?></h1>

und rufst die mal ab.

[dedlfix]

Tach!

Jetzt baust Du eine test.php:

<h1>Dieser Server auf <?=$_SERVER["HOSTNAME"] ?>funktioniert mit PHP <?=phpversion() ?></h1>

und rufst die mal ab.

Mach es nicht so kompliziert. Einfach nur <?php phpinfo();

dedlfix.

[Indianerversteher]

Mach es nicht so kompliziert. Einfach nur <?php phpinfo();

phpinfo() empfehle ich für Tests nicht mehr seit ich mitbekommen habe, dass es Hoster gibt, die das allen Erstes in der php.ini sperren - was dann nur für weitere Verwirrung sorgt.

Wenn schon, dann das hier.

[Klaus1]

Jetzt baust Du eine test.php:

<h1>Dieser Server auf <?=$_SERVER["HOSTNAME"] ?>funktioniert mit PHP <?=phpversion() ?></h1>

und rufst die mal ab.

---request begin---
GET /test/test.php HTTP/1.1
User-Agent: Wget/1.14 (linux-gnu)
Accept: */*
Host: mydomain.net
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 200 OK
Date: Fri, 05 Jul 2019 13:00:31 GMT
Server: Apache
X-Powered-By: PHP/7.0.7
Content-Length: 54
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8

---response end---

Hey, diese Datei konnte ich im Browser aufrufen. Einen "Fehler" hab ich dadurch finden können, durch die Neuinstallation von PHP7 sind meine Einstellungen aus der alten php.ini verloren gegangen. Dort hatte ich ein paar Kleinigkeiten eingestellt (insbesondere short_open_tag):

	short_open_tag = On
	max_execution_time = 1200
	memory_limit = 512M
	error_reporting = E_ALL & ~E_NOTICE
	post_max_size = 16M
	upload_max_filesize = 32M

Nach einem erneuten Restart funktionieren jetzt einige Seiten, bei einigen wird aber noch immer die php-Datei als Download angeboten ???

LG Klaus

[Indianerversteher]

Nach einem erneuten Restart funktionieren jetzt einige Seiten, bei einigen wird aber noch immer die php-Datei als Download angeboten ???

Wie schon gesagt: Lösche den Browser-Cache. (Ich hoffe, Du hast bei irgendwelchen früheren Versuchen nicht auch noch einen Proxy mit Müll gefüttert.)

Antwort 2:

Prüfe mit

URL="http://example.com/or/what/ever";
wget -d -O - $URL

was da gesendet wird.

[Klaus1]

Wie schon gesagt: Lösche den Browser-Cache. (Ich hoffe, Du hast bei irgendwelchen früheren Versuchen nicht auch noch einen Proxy mit Müll gefüttert.)

Hmm, nach dem Löschen des Cache (und Neustart des Browsers), bekomme ich tatsächlich keine php-Dateien mehr als Download angeboten.

Vielen lieben Dank für die Unterstützung. 😍

Dann darf ich mich jetzt damit befassen, was sich alles geändert hat und was alles angepasst werden muss, damit alle Seiten auch wieder unter php7 funktionieren. 😟

LG Klaus

[Indianerversteher]

Dann darf ich mich jetzt damit befassen, was sich alles geändert hat und was alles angepasst werden muss, damit alle Seiten auch wieder unter php7 funktionieren.

So wild ist das nicht.

Vieles findet man schnell mit

cd /var/www/wohin-auch-immer
grep -R "Suchbegriff" > /tmp/liste.txt; less /tmp/liste.txt

[Indianerversteher]

cd /var/www/wohin-auch-immer
grep -Rn "Suchbegriff" > /tmp/liste.txt; less /tmp/liste.txt

Die Option n sorgt dafür, dass von grep auch die Zeilennummern der Treffer angezeigt werden. mit vi DATEI +123 kann man dann die Datei zum Editieren öffnen und direkt zur Zeile (hier 123) springen.

[Indianerversteher]

max_execution_time = 1200

Das sind 20 Minuten!

Ist Dir bewusst, dass auch ein großzügig konfigurierter Apache nur eine begrenzte Anzahl solcher Prozesse bearbeiten kann? Sind alle Kinder vollbeschäftigt kann der Indianer keine neuen Requests mehr annehmen.

Zur Vermeidung von DoS-Attacken würde ich eine solche Einstellung vermeiden (ggf. nur für bestimmte, nicht wirklich öffentliche Verzeichnisse setzen -> .user.ini. Oder eben den eigentlichen, langdauernden Prozess mit etwas wie

$tmpfile = trim(`mktemp`);
$job   = intval(`echo "foo.sh -k bar > $tmpfile" | batch; atq | tail -n1`);

auslagern und schauen wie ich den Nutzer nach Abarbeitung informiere (zb. per mail)

• Vorausetzungen: Dazu muss das Paket 'at' installiert sein.
• Literatur: man batch

post_max_size = 16M
upload_max_filesize = 32M

Ohnehin stellt sich also die Frage, was ein Server ganze 20 Minuten lang mit nur 16 bzw. 32 Megabyte Daten machen soll...

[Indianerversteher]

<?php
$tmpfile   = trim(`mktemp`);
$errFile   = $tmpfile . '.err';

$postFile  = $tmpfile . '.post';
file_put_contents( $postFile, serialize( $_POST )

session_start();
$sessFile  = $tmpfile . '.sess';
file_put_contents( $sessFile, serialize( $_SESSION );

$jobString = 'script.sh'. ' ' . $tmpfile;

$jobNumber = intval(`echo "'$jobString > $tmpfile 2> $errFile'" | batch 2>&1 | tail -n1 | cut -d ' ' -f2`);

echo "Job-Nummer: " . $jobNumber . "\n";
?>

Das ist immer noch ein Beispiel. script.sh bekommt den Name der temporären Datei und kann damit auch die Daten, z.B. $_POST, $_SESSION aus den weiteren temporären Dateien lesen. Das Skript hat dann den Job zu erledigen, den Müll wegzuräumen und dem Benutzer per Mail einen individuellen Link zu einer Ressource mit den Ergebnissen (die stehen dann hoffentlich in $tmpfile und können hoffentlich ausgewertet werden) zu senden.

Wer die Angabe machen will wie viele Jobs noch offen sind: Der Linux-Befehl atq liefert eine nette Liste...

[TS]

Hello,

schau dir das Manual zu post_max_size nochmal an.

	short_open_tag = On
	max_execution_time = 1200
	memory_limit = 512M
	error_reporting = E_ALL & ~E_NOTICE
	post_max_size = 16M
	upload_max_filesize = 32M

Das sollte größer sein, als upload_max_filesize

Glück Auf
Tom vom Berg

[Der Martin]

Hallo Klaus,

Lösch mal den Cache des Browsers und versuch es nochmal.

Das sollte theoretisch mit einem Shift-Reload getan sein oder?

eigentlich ja, aber es liegt im Ermessen des Browsers. Verlassen würde ich mich nicht drauf.

---response begin---
HTTP/1.1 200 OK
Date: Fri, 05 Jul 2019 12:43:29 GMT
Server: Apache
X-Powered-By: PHP/7.0.7
Content-Length: 7266
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
---response end---

Also text/html als Content-Type klingt ja schon mal gesund. Und der X-Powered-By-Header sagt, dass da auch wirklich PHP seine Finger im Spiel hatte. So ganz falsch kann die Serverkonfiguration also nicht sein.
Aber welcher Browser bietet dann die empfangene Ressource zum Speichern an?

Ciao,
 Martin

[Indianerversteher]

Aber welcher Browser bietet dann die empfangene Ressource zum Speichern an?

Derjenige, der Müll aus vorhergehenden Versuchen zusammen mit der Weisung, bis zu einem fern liegenden Zeitpunkt den Server nicht belästigen, im Cache hat.

[Klaus1]

Aber welcher Browser bietet dann die empfangene Ressource zum Speichern an?

Derjenige, der Müll aus vorhergehenden Versuchen zusammen mit der Weisung, bis zu einem fern liegenden Zeitpunkt den Server nicht belästigen, im Cache hat.

Wenn eine Original-php-Datei beim Browser zum Download angeboten wird, bedeutet das meinem Verständnis nach, dass die Datei serverseitig nicht ausgeführt wurde, da sonst nur die Ausgaben der Datei an den Client (=Browser) übertragen wird. Dem Browser ist der Dateityp php unbekannt und daher bietet er den Download an.

LG Klaus

[Indianerversteher]

Wenn eine Original-php-Datei beim Browser zum Download angeboten wird,

Wenn bei irgendwelchen versuchen eine "Original-php-Datei" zusammen mit dem passenden Content-Type und Anweisungen, das Zeug zu cachen an dem Browser geschickt wurde, dann merkt sich das der/mancher Browsercache auch und deshalb fragt der Browser den Server manchmal gar nicht erst nochmal sondern fragt einfach nochmal, wo Du Dir das hinstecken willst.

Einfach den Browsercache löschen. Das tut nicht weh!

[dedlfix]

Tach!

Einfach den Browsercache löschen. Das tut nicht weh!

Noch besser, wie auch schon erwähnt, die Browsertools öffnen und im Netzwerk-Tab den Cache disablen. Zudem kann man dort auch sehen, ob ein Request aus dem Cache beantwortet wurde oder vom Server kam (also, wenn der Cache nicht disabled ist).

dedlfix.

[Indianerversteher]

Noch besser, wie auch schon erwähnt, die Browsertools öffnen und im Netzwerk-Tab den Cache disablen.

Dann bietet er nach dem Schließen der Browsertools (womöglich) den alten und falschen Mist aus den früheren Versuchen wieder an…

[Der Martin]

Hallo,

Wenn eine Original-php-Datei beim Browser zum Download angeboten wird, bedeutet das meinem Verständnis nach, dass die Datei serverseitig nicht ausgeführt wurde, da sonst nur die Ausgaben der Datei an den Client (=Browser) übertragen wird.

korrekt.

Dem Browser ist der Dateityp php unbekannt und daher bietet er den Download an.

Dem Browser hat der Name egal zu sein; was zählt, ist der Content-Type-Header. Solange der text/html lautet, hat der Browser den Datenmüll als HTML zu interpretieren. Ob der Name der Ressource dabei auf .html, .php oder .daddy endet, hat ihn nicht zu interessieren.

Einzig der Internet Explorer war früher berüchtigt dafür, dass er dem Content-Type-Header kaum Beachtung geschenkt hat und stattdessen den Ressourcentyp aus dem Kontext und sogar aus dem Inhalt erraten hat. Dem konnte man ein Dokument mit einem völlig verkorksten Content-Type andrehen - solange irgendwo nah am Anfang ein <html vorkam, hat er's stur als HTML gerendert.

Ich meine aber, das sei schon lange nicht mehr so.

Schönes Wochenende,
 Martin

[TS]

Hello,

••• und Server neu gestartet?

Glück Auf
Tom vom Berg

[Der Martin]

Hallo Tom,

••• und Server neu gestartet?

aus dem Anfangsbeitrag:

und aktiviert:

a2enmod php7
service apache2 restart

Beantwortet das deine gutgemeinte Rückfrage?

Schönes Wochenende,
 Martin

[Indianerversteher]

… und Server neu gestartet?

Das führt mich zusammen mit dem erwähntem "zypper" zu folgender Rückfrage:

SuSE?

Ist das noch so, dass in /etc/apache2/httpd.conf etwas von "DO NOT EDIT THIS FILE" steht und demnach /etc/sysconfig/apache2 zu editieren ist (wo auch der Yast rumschreibt) - weil bei einem restart die Konfiguration des Apache aus /etc/sysconfig/apache2 neu erzeugt wird?

[Klaus1]

Ist das noch so, dass in /etc/apache2/httpd.conf etwas von "DO NOT EDIT THIS FILE" steht und demnach /etc/sysconfig/apache2 zu editieren ist (wo auch der Yast rumschreibt) - weil bei einem restart die Konfiguration des Apache aus /etc/sysconfig/apache2 neu erzeugt wird?

Hmm, es gibt tatsächlich eine /etc/sysconfig/apache2 Datei. Wenn ich den HTTP-Server über Yast aufrufe, sehe ich auch unter dem Reiter Haupthost, dass IncludeOptional auf /etc/apache2/conf.d/*.conf steht. Unter unter Server-Module ist PHP7 aktiviert.

Auch ein kompletter Neustart des Servers hat keine Änderung gebracht.

LG Klaus

[Indianerversteher]

Das hat sich durch Deine andere Antwort als "egal" herausgestellt.

[TS]

Hello Martin,

••• und Server neu gestartet?

aus dem Anfangsbeitrag:

und aktiviert:

a2enmod php7
service apache2 restart

Beantwortet das deine gutgemeinte Rückfrage?

Hatte ich wohl übersehen.

Dir auch ein schönes Wochenende,

Glück Auf
Tom vom Berg