PHP wird nicht interpretiert sondern zum Download angeboten!

[djmcm]

Mein Problem:
PHP-Seiten werden nicht geparsed.

Wenn ich auf folgenden Link klicke, bietet er mir die Datei zum download an.
http://www.linux-iso-download.de/index.php
(siehe http://www.linux-iso-download.de/download.jpg)

Vorweg: Ja PHP läuft.

Kann mir da jemand weiterhelfen?

Hab SuSe 9.0 laufen (Server von S4Y).

THX Markus

[michaelvogt]

Hallo.

Ist im httpd.conf php mit AddType bekannt gemacht worden?


Viele Grüße,
Michael Vogt

[djmcm]

Ja steht bei mir in mod_php4.conf drinnen

Code: Select all

<IfModule sapi_apache2.c>
        AddType application/x-httpd-php .php
        AddType application/x-httpd-php .php3
        AddType application/x-httpd-php .php4
        AddType application/x-httpd-php-source .phps
        DirectoryIndex index.php
        DirectoryIndex index.php3
        DirectoryIndex index.php4
</IfModule>

Vielleicht sollte ich noch dazusagen, dass PHP auf anderen Seiten die auf dem Server liegen teilweise interpretiert wird. D.h. mein Problem tritt nicht überall und nicht immer auf, sondern nur sporadisch.

[djmcm]

Okay danke, mittlerweile hat sich das Problem gelöst.

[michaelvogt]

Was war die Lösung?


Viele Grüße,
Michael Vogt

[djmcm]

Hab folgendes gemacht:

PHP Version 4.3.3 --> 4.3.8
Apache Version 2.0.48 -->2.0.50
Apache gerestartet.

Nun gehts wieder.

[blacksavior]

Hallo zusammen,
das PHP-Download-Problem hat im Forum ja ´ne Menge paralleler Beiträge. Ich nehm mal einfach diesen.

Hat jemand schon den definitiven Grund und somit auch den ultimativen Lösungsweg für dieses Problem gefunden? Ich frage, weil jeder Beitrag zu einem anderen Lösungsweg kommt, und die Lösung jeweils in einem anderen Beitrag zerissen wird da es nicht laufen soll?
In einem Beitrag heißt es z. B.

Apache Update auf 2.0.50 -> Keine Webseiten erreichbar
PHP Update auf 4.3.8 -> Keine Webseiten erreichbar

was ja im Widerspruch zu diesem Thread steht.

Bitte postet mal kurz, welcher Lösungsweg bei euch geklappt und wecher nicht bei euch geklappt hat, damit wir hier ein kleines HowToDo, bzw. HowNotToDo bekommen.

Unsere Gemeinsamkeiten:
Scheinbar haben wir alle das aktuelle 1&1 Suse 9.0 oder 9.1 Image (oder etwas äquivalentes)
Suse 9.x; Apache 2.0.4x; PHP 4.3.x
Ich habe Suse 9.1, Apache 2.0.49; PHP 4.3.4 (alles Original 1&1 Image)

gruß blacksavior

[gleitz]

@ blacksavior,

deinen Bemühungen in Ehren. Jeder Einzelne mit seinen gleichen gelagerten Problem hat nie exakt genug beschrieben wie sein System aufgebaut ist, was die Log sagen usw.

Wenn man seinen Server so lässt wie er ist, dann dürfte es die Probleme nie geben, ansonsten sofort Support kontaktieren. Dann ist das erst mal ihre Problem. Ich kann ja als Kunde verlangen ein anständiges Produkt zu bekommen.
Das erste was alle machen ist ein php-Update. Es rückt aber so gut wie keiner richtig damit heraus was er noch alles angestellt hat und schon gehen die Probleme los.

Ich habe in der zwischenzeit alle meinen Server von SuSE Apache2 befreit und etwas mehr "Eigenverantwortung" einfließen lassen.

Das ganze hatte ich erst mal tagelang auf einem lokalen Rechner getestet. Dabei hatte ich jeden der hier in der letzten Zeit gemeldeten Fehler und immer lag die Schuld nicht an der Software, sondern an mir.

• Da hat der ServerRoot Pfad nicht gestimmt, weil man die alte httpd.conf blind übernommen hatte, und und und.
• Server ist nicht gestartet, weil die Apache2 Runtime Library nicht automatisch mit dem Apache2 deinstalliert wird.
• Weil irgendwelche alte Fragmente der deinstallierten Programme noch irgendwie in die Quere gekommen sind
• usw. usw.

Von den ganzen Probleme hatte ich alle in Eigeninitiative beseitigt. Zwischendurch was ich so am verzweifeln, das ich beinahe ich Schreibtischplatte durchgebissen hätte.
Letztendlich steht alles was man wissen muss in den Log, in der Doku vom Apache2 und hier im Forum in älteren Beiträgen. [/list]

[blacksavior]

Hi,
leider ist das Problem bei mir und auch bei anderen schon in der Standartinstallation von 1&1 aufgetreten. Laut 1&1 Support liegt es entweder an PHP 4 oder an Apache 2. Das Problem sei bekannt. Je nach dem wen man bei denen an den Hörer bekommt, hat man eine andere Aussage. Schönen dank 1&1!

Ich hab das Problem seit dem letzten zurücksetzen des Servers. Hab das Image Suse 9.1 mit Confixx 3.03 aufspielen lassen. Habe an keinem Systemprozess etwas geändert. Trotzdem bieten einzelne Apache 2 Childs nach längerer Zeit PHP zum Download an.
Das Problem wird somit immer mehr User treffen, da ich mal vermuten darf, das 1und1 das Image erst mit einem neuen release seitens Suse ändern wird.

[gleitz]

Ok, der "kleine" Unterschied ist, das mein System auf SuSE 9.0 aufsitzt. Das dürfte aber nicht der gravierende Unterschied sein, sondern das ich mich bei wichtigen Elementen von den RPM-Paketen verabschiedet habe und alles nach meinen persönlichen Bedürfnissen angepasst habe.

Zum Apache...
Suse baut den Apache2 wie folgt.

8< Schnipp
Name: apache2
%define pname apache2
%define vers 2
%define httpd httpd2
%define apache_mmn %(test -s %{S:0} && { echo -n apache_mmn_; bzcat %{S:0} | awk '/^#define MODULE_MAGIC_NUMBER_MAJOR/ {printf "%d", $3}'; })
%define default_mpm prefork
%{!?perchild:%define perchild 0}
%{!?prefork:%define prefork 1}
%{!?worker:%define worker 1}
%{!?leader:%define leader 1}
%{!?metuxmpm:%define metuxmpm 1}
%define mpms_to_build %(test %perchild = 1 && printf perchild) %(test %prefork = 1 && printf prefork) %(test %worker = 1 && printf worker) %(test %leader = 1 && printf leader) %(test %metuxmpm = 1 && printf metuxmpm)
# dir names
%if %suse_version > 800
%define datadir /srv/www
%else
%define datadir /usr/local/httpd
%endif
%define htdocsdir %{datadir}/htdocs
%define manualdir %{_prefix}/share/%{pname}/manual
%define errordir %{_prefix}/share/%{pname}/error
%define iconsdir %{_prefix}/share/%{pname}/icons
%define cgidir %{datadir}/cgi-bin
%define localstatedir /var/lib/apache2
%define proxycachedir /var/cache/apache2
%define logfiledir /var/log/apache2
%define runtimedir /var/run
%define sysconfdir /etc/apache2
%define includedir %{_includedir}/%{pname}
%define libexecdir %_libdir/%{pname}
%define installbuilddir %{_prefix}/share/%{pname}/build
%define userdir public_html

>8 Schnapp
8< Schnipp

%build
#
# O/ |_ o| _|
# /O |_)|_|||(_|
#
function configure {
CFLAGS="$RPM_OPT_FLAGS -fPIC -Wall -fno-strict-aliasing %{?lfs_flags:%lfs_flags}"
CPPFLAGS="-DSSL_EXPERIMENTAL_ENGINE -DMAX_SERVER_LIMIT=200000"
./configure
--enable-maintainer-mode
--enable-layout=SuSE81%(test "%_lib" = lib64 && echo -n _64)
--with-program-name=httpd%{vers}$mpm_suffix
--with-mpm=$mpm
--with-perl=`which perl`
%if "$mpm" == "leader"
%ifarch %ix86
%ifnarch i386 i486
--enable-nonportable-atomics=yes
%endif
%endif
%endif

--enable-mods-shared=all
--enable-ssl=shared

--disable-isapi
--enable-deflate
--enable-echo
--enable-ext-filter
--enable-charset-lite
--enable-file-cache
--enable-logio
--enable-case_filter
--enable-case_filter_in

--with-ldap
--enable-ldap
--enable-auth_ldap

--enable-proxy
--enable-proxy-connect
--enable-proxy-ftp
--enable-proxy-http
--enable-cache
--enable-disk-cache
--enable-mem-cache

--enable-suexec
--with-suexec-bin=%{_sbindir}/suexec%{vers}
--with-suexec-caller=wwwrun
--with-suexec-docroot=%{htdocsdir}
--with-suexec-logfile=%{logfiledir}/suexec.log
--with-suexec-userdir=%{userdir}
--with-suexec-uidmin=96
--with-suexec-gidmin=96
--with-suexec-safepath="/usr/local/bin:/usr/bin:/bin"
}
>8 Schnapp

Das SuSE 8.1 Layout sieht in etwa wie folgt aus.

<Layout MeinServer>
prefix: /usr
exec_prefix: ${prefix}
bindir: ${prefix}/bin
sbindir: ${prefix}/sbin
libdir: ${prefix}/lib
libexecdir: ${prefix}/lib/apache2
mandir: ${prefix}/share/man
sysconfdir: /etc/apache2
datadir: /srv/www
installbuilddir: ${prefix}/share/apache2/build
errordir: ${prefix}/share/apache2/error
iconsdir: ${prefix}/share/apache2/icons
htdocsdir: ${datadir}/htdocs
manualdir: ${prefix}/share/apache2/manual
cgidir: ${datadir}/cgi-bin
includedir: ${prefix}/include/apache2
localstatedir: /var/lib/apache2
runtimedir: /var/run
logfiledir: /var/log/apache2
proxycachedir: /var/cache/apache2
</Layout>

Absolut korrekt im SuSE-Layout wäre, wenn der Präfix auf /srv/www zeigen würde und alle ${prefix} Einträge mit /usr ersetzt werden würde. Nur dann würdest du ebenfalls deine Schreibtischplatte durchbeißen.

Jetzt dürfest du eigentlich genug Infos als Basis haben, um den SuSE Apache2 zu killen und durch eine vernünftige Eigenproduktion zu ersetzen.

PS: Es geht schneller eine neu erzeugte httpd.conf einzurichten, als das SuSE-Zeug zu korrigieren.

[Roger Wilco]

Soweit ich sehen kann handelt es sich wohl um folgenden Bug:
http://bugs.php.net/bug.php?id=25753 (bei den PHP-Jungs)
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26706 und http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25949 (bei den Apache-Leuten, nur ein Hinweis auf php.net).

Eine konkrete Lösung ist aber in keinem der Bugreports zu finden :(