Guten Tag,
seit 2 Tagen beschäftigt mich das Problem...:
[info: auf einem alten suse9.0-root-Server läuft es ohne Probleme...]
Ziel: ein verstecktes Verzeichnis nur für admins (.htaccess) soll tools enthalten, die z.b. Systemauskünfte geben (z.B. phpinfo, nqt.php und einige andere mehr...
Das "versteckt" ist nicht das Thema. die php-Dateien sind sichtbar, lassen sich nicht ausführen.
Das gestrige Problem, cgi und pl ausführen zu lassen, wurde gelöst. g*ttseidank.
Es bleibt derzeit nur php übrig.
Infos zum System:
==============
[mein problem ist bestimmt apache-versions-unabhängig...]
aus der error_log
[warn] Init: Session Cache is not configured [hint: SSLSessionCache]
007] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec2)
007] [notice] Digest: generating secret for digest authentication ...
007] [notice] Digest: done
007] [notice] Apache/2.2.4 (Linux/SUSE) mod_ssl/2.2.4 OpenSSL/0.9.7n-dev PHP/5.2
[das SSLSessionCache ist -denke ich- zu vernachlässigen, erstmal...]
loadmodule.conf sagt:
suexec,suphp,php5,perl sind u.a. dabei
[denke mal, überall die neuesten Versionen installiert/teilweise kompiliert zu haben; das dürfte nicht das Problem sein...]
suexec.log sagt:
uid: (1003/werauchimmer.de) gid: (103/103) cmd: zz.pl
uid: (1003/werauchimmer.de) gid: (103/103) cmd: env.pl
[damit ist das gestrige Problemkapitel für cgi/pl gelöst...]
access_log sagt:
12.345.67.89 - zzz [08/Mar/2007:18:57:02 +0100] "GET /admin/phpinfo.php HTTP/..
12.345.67.89 - zzzx [08/Mar/2007:19:06:11 +0100] "GET /admin/nqt.php HTTP/1.1"
[zzz ist der authorisierte user...]
parallel probiert, auf dem alten server, sieht das log so aus:
84.179.212.99 - zzz [08/Mar/2007:20:18:30 +0100] "GET /admin/phpinfo.php HTTP/1
84.179.212.83 - zzz [08/Mar/2007:20:18:31 +0100] "GET /admin/phpinfo.php?=PHPE968F35-D428-11d2-A.....
84.179.212.83 - zzz [08/Mar/2007:20:18:31 +0100] "GET /admin/phpinfo.php?=PHPE968F35-D428-11d2-A.....
'finde nirgends fehler....
es sei denn, der fehler sitzt VOR dem monitor, wie so oft. DAS wird es auch sein. Nur: ich sehe es mal wieder nicht.
info: ich habe die cgi/pl/php's in KEINEM speziellen verzeichnis, es gibt kein /cgi-dir o.ä. ....
Ein Blick in die httpd.conf
[Auszüge aber in der Reihenfolge]:
=========================
die confs aus /conf.d werden eingebunden (mod_perl,php5)
Include /etc/apache2/sysconfig.d/loadmodule.conf
TypesConfig /etc/apache2/mime.types
#damit klappts bei cgi pl 3/2007
<Directory />
Options -Indexes +FollowSymLinks +Includes
AllowOverride All
</Directory>
<IfModule mod_suphp.c>
suPHP_Engine on
php_admin_flag engine off
AddType application/x-httpd-php .php
AddType application/x-httpd-php .php3
AddType application/x-httpd-php .php4
AddHandler x-httpd-php .php
DirectoryIndex index.php
DirectoryIndex index.php3
DirectoryIndex index.php4
</IfModule>
<Directory "/home/*/public_html/admin">
Options +ExecCGI
</Directory>
AddHandler cgi-script .cgi .pl
AddType application/x-httpd-cgi .cgi
DANN kommen die virtuellen server:
php_admin_value open_basedir /home/11111.de/public_html/:/usr/local/lib/php_admin_value session.save_path /tmp/
php_admin_flag register_globals On
php_admin_flag engine off
php_admin_flag safe_mode off
php_admin_flag display_errors on
SuexecUserGroup werauchimmer.de www
Achso: die Rechte:
==============
phpinfo.php hat (0644)
für werauchimmer.de/www
Das subdir, in dem phpinfo.php liegt, hat:
werauchimmer.de/www (0755)
Was habe ich zu Problemlösung getan, ehe ich hier um Hilfe "brülle"? ;-)
-div apache-Bücher zu den einzelnen Direktiven durchgelesen,
-google-Anfragen gestellt (bringt wenig!, das Problem ist zu allgemein...)
-hier im Forum div. Howto's gelesen, gestern zu einem von server4downs a bissl senf dazugegeben...
--die Howto's nachgearbeitet, einzelne Änderungen NACHEINANDER ;-) durchgespielt (httpd neugestartet etc etc)...
-gerätselt, verglichen, geraten ;-)
jetzt bin ich ratlos, und doch überzeugt, daß ich was übersehen habe.. nur was?
Ich danke fürs Mitlesen, und wer die Lösung, oder den Gedankenstubbser hat, dem sei im Voraus gedankt.
viele grüße
klaus
PS: Nachtrag 10 min. später:
suphp (neue Version 0.6.2 hat NEU: eine .conf..... autsch, ist das mein Fehler?
die alte suphp kannte keine conf.-datei...., auf dem suse9.0-server....
PS2: Nachtragender Nachtrachshaushalt 30 min. später
endlich kommen Fehlermeldungen, endlich spricht wer? (-> suphp) mit mir:
aus error_log (apache2)
..IOException in File.cpp:44: Could not open file /usr/local/etc/suphp.conf
Premature end of script headers: index.php
s.a. hierzu suphp-0.6.2/doc/apache/CONFIG ;-)
PS3 (geschrieben nach dem nötigen Schlaf, mit der Erkenntnis, daß man sich mal wieder verrannt hat ;-))
andere Erkenntnis: die doku von suphp ist mau. es ist eher eine sudoku ;-)
nicht alles ist dokumentiert, ein Blick in den Quellcode ist manchmal nötig (es wurden hier schon im Forum einige Tip(p)s gegeben...)
Was mich [ver]stört ist folgendes: (mir) nicht ganz klar ist die Funktion von suphp: ist es Ziel die php's als cgi ablaufen zu lassen? und warum sagt der Programmierer von suphp, ein mod_php[4.5] sei parallel unerwünscht?!
...
Mittlerweile sind alle Fehler, die beim PS2 gesichtet wurden, eliminiert. Nur die php-Dateien wollen weiterhin runtergeladen werden.
? Halt! Stimmt so nicht. Es gibt einige php's, die werden zum Download angeboten, bei anderen kommt Fehler500 (apache2).
Ist es Header-Problem? Das kommt mir irgendwie bekannt vor.... bin kein html/php-Codierer... ;-)
Als nächsten Lösungsansatz sehe ich nur noch die Kompilaierung von dem alten suphp, wie es unter suse9.0 noch läuft, parallel DORT zu php4... Mist, daß kann nicht die Lösung sein, alte Programme einzusetzen; aber die php's müssen endlich(!) laufen.
Hat denn keiner von den 15 Mitlesern, die hier bislang den Artikel angeklickst haben, eine Idee? 2 Tage hänge ich an dem Zeuchs, aber es ist ja nicht so, daß man nur die ganze Zeit DAS rumprobiert, nee es iss ne unnötige (Zeit kostende) Baustelle... ;-)
grüezi, Klaus (Freitag, 9.04h)
PS4: nach 20 Minuten (sorry, wenn dieser Dialog nervt, aber mich nervt das Problem noch mehr ;-) ]
suphp052 geht NICHT unter apache224 zu kompilieren (erst mit suphp 026) .merde.
in der faq von S.marschning (suphp-schöpfer) liest sich was vbon cli-modus von php, wir bräuchten die cgi-version?
ja, bitte, wie das herausfinden phpinfo geht nicht. aber kleinklausi hat eine Idee:
php -i > xxx ; dann xxx lesen. php ist als cli kompiliert. das ist wohl normal. aber wird denn eben nicht imemr gesagt/geschrieben, nicht als cgi laufen lassen? warum laufen denn bei mir meine php's nicht als cli. moment.... auf dem alten server ist php -i > xxx zwar wesentlich schlechter zu lesen..., da steht das php 4.3.11 so --enable-force-cgi-redirect compiliert wurde.... AUTSCH. ist DAS das problem? es musß als cgi kompiliert werden? warum sgt das denn keiner (wer denn?) einem?
chaos im hirn.... ;-)
PS5 (Freitag, 11.45) schade, daß hier keiner was beiträgt....
mittlerweile interessanten stoff gefunden:
PHP: PHP auf der Kommandozeile - Manual
hier infos cli versus cgi
-> es sieht so aus, als man sein php neu kompilieren muss...
(wie das vorhandene php kompiliert wurde, findet man mit php -i heraus (umlenken!)
Nachträge zur Wissenerlangung ;-)
PHP: Probleme bei der Compilierung - Manual 54.10 ist interessant!
ebenso: PHP: PHP auf der Kommandozeile - Manual (ausdrucken!) ;-)
PS6 (und Ende) Freitag 20.20
die php(5)-Skripte laufen.
(los)Lösung/(not)Lösung/Losung des Tages war: man installiere php als cgi
Ich habe ca 6 Std gebraucht, um Abhängigkeiten zu erkennen(!), sie dann aufzulösen, php_zum_widerholten_male_zu_konfiggern. uff (und das bei einem x64... ;-)
das readline-Problem war keines, obwohl configure es meinte, es war libedit: hat mich ca 2 Stunden "gekostet". es war hammerhart. (=libedit.so.... 0.0.22 musste her!!!!aus: libedit-2.9.snap20~1022-10.x86_64.rpm); ich glaube apache2 habe ich deinstallen müssen... ;-), prinzipiell sollte auf die readline-version geachtet werden. ich weiss nicht, ob das meinem 64bit opensuse10-abhöngig ist....(?)
man hat gelernt ;-)
auch wichtig bei der ganzen choose: ruhig blut. auch wenn es mal den bach runtergeht. zeitweilig war yast und der mc nicht aufzurufen. ;-)
-Immerhin haben hier 24 mitgelesen. nur hat keiner war geschrieben, ausser olle icke. hm. nunja/ninja: selbst ist der man
. ;-)
-wen Einzelheiten interessieren, ich gebe gerne Auskunft.
-was ich nicht kapiere: sind die Modi cli und cgi bei der php-Kompilierung nicht gleichzeitig kompilierbar? Muss man sich für den cgi-Modus entscheiden?
-wie war das bitte noch mal mit der Sicherheit? Was sprach gegen den cgi-Modus?
seit 2 Tagen beschäftigt mich das Problem...:
[info: auf einem alten suse9.0-root-Server läuft es ohne Probleme...]
Ziel: ein verstecktes Verzeichnis nur für admins (.htaccess) soll tools enthalten, die z.b. Systemauskünfte geben (z.B. phpinfo, nqt.php und einige andere mehr...
Das "versteckt" ist nicht das Thema. die php-Dateien sind sichtbar, lassen sich nicht ausführen.
Das gestrige Problem, cgi und pl ausführen zu lassen, wurde gelöst. g*ttseidank.
Es bleibt derzeit nur php übrig.
Infos zum System:
==============
[mein problem ist bestimmt apache-versions-unabhängig...]
aus der error_log
[warn] Init: Session Cache is not configured [hint: SSLSessionCache]
007] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec2)
007] [notice] Digest: generating secret for digest authentication ...
007] [notice] Digest: done
007] [notice] Apache/2.2.4 (Linux/SUSE) mod_ssl/2.2.4 OpenSSL/0.9.7n-dev PHP/5.2
[das SSLSessionCache ist -denke ich- zu vernachlässigen, erstmal...]
loadmodule.conf sagt:
suexec,suphp,php5,perl sind u.a. dabei
[denke mal, überall die neuesten Versionen installiert/teilweise kompiliert zu haben; das dürfte nicht das Problem sein...]
suexec.log sagt:
uid: (1003/werauchimmer.de) gid: (103/103) cmd: zz.pl
uid: (1003/werauchimmer.de) gid: (103/103) cmd: env.pl
[damit ist das gestrige Problemkapitel für cgi/pl gelöst...]
access_log sagt:
12.345.67.89 - zzz [08/Mar/2007:18:57:02 +0100] "GET /admin/phpinfo.php HTTP/..
12.345.67.89 - zzzx [08/Mar/2007:19:06:11 +0100] "GET /admin/nqt.php HTTP/1.1"
[zzz ist der authorisierte user...]
parallel probiert, auf dem alten server, sieht das log so aus:
84.179.212.99 - zzz [08/Mar/2007:20:18:30 +0100] "GET /admin/phpinfo.php HTTP/1
84.179.212.83 - zzz [08/Mar/2007:20:18:31 +0100] "GET /admin/phpinfo.php?=PHPE968F35-D428-11d2-A.....
84.179.212.83 - zzz [08/Mar/2007:20:18:31 +0100] "GET /admin/phpinfo.php?=PHPE968F35-D428-11d2-A.....
'finde nirgends fehler....
es sei denn, der fehler sitzt VOR dem monitor, wie so oft. DAS wird es auch sein. Nur: ich sehe es mal wieder nicht.
info: ich habe die cgi/pl/php's in KEINEM speziellen verzeichnis, es gibt kein /cgi-dir o.ä. ....
Ein Blick in die httpd.conf
[Auszüge aber in der Reihenfolge]:
=========================
die confs aus /conf.d werden eingebunden (mod_perl,php5)
Include /etc/apache2/sysconfig.d/loadmodule.conf
TypesConfig /etc/apache2/mime.types
#damit klappts bei cgi pl 3/2007
<Directory />
Options -Indexes +FollowSymLinks +Includes
AllowOverride All
</Directory>
<IfModule mod_suphp.c>
suPHP_Engine on
php_admin_flag engine off
AddType application/x-httpd-php .php
AddType application/x-httpd-php .php3
AddType application/x-httpd-php .php4
AddHandler x-httpd-php .php
DirectoryIndex index.php
DirectoryIndex index.php3
DirectoryIndex index.php4
</IfModule>
<Directory "/home/*/public_html/admin">
Options +ExecCGI
</Directory>
AddHandler cgi-script .cgi .pl
AddType application/x-httpd-cgi .cgi
DANN kommen die virtuellen server:
php_admin_value open_basedir /home/11111.de/public_html/:/usr/local/lib/php_admin_value session.save_path /tmp/
php_admin_flag register_globals On
php_admin_flag engine off
php_admin_flag safe_mode off
php_admin_flag display_errors on
SuexecUserGroup werauchimmer.de www
Achso: die Rechte:
==============
phpinfo.php hat (0644)
für werauchimmer.de/www
Das subdir, in dem phpinfo.php liegt, hat:
werauchimmer.de/www (0755)
Was habe ich zu Problemlösung getan, ehe ich hier um Hilfe "brülle"? ;-)
-div apache-Bücher zu den einzelnen Direktiven durchgelesen,
-google-Anfragen gestellt (bringt wenig!, das Problem ist zu allgemein...)
-hier im Forum div. Howto's gelesen, gestern zu einem von server4downs a bissl senf dazugegeben...
--die Howto's nachgearbeitet, einzelne Änderungen NACHEINANDER ;-) durchgespielt (httpd neugestartet etc etc)...
-gerätselt, verglichen, geraten ;-)
jetzt bin ich ratlos, und doch überzeugt, daß ich was übersehen habe.. nur was?
Ich danke fürs Mitlesen, und wer die Lösung, oder den Gedankenstubbser hat, dem sei im Voraus gedankt.
viele grüße
klaus
PS: Nachtrag 10 min. später:
suphp (neue Version 0.6.2 hat NEU: eine .conf..... autsch, ist das mein Fehler?
die alte suphp kannte keine conf.-datei...., auf dem suse9.0-server....
PS2: Nachtragender Nachtrachshaushalt 30 min. später
endlich kommen Fehlermeldungen, endlich spricht wer? (-> suphp) mit mir:
aus error_log (apache2)
..IOException in File.cpp:44: Could not open file /usr/local/etc/suphp.conf
Premature end of script headers: index.php
s.a. hierzu suphp-0.6.2/doc/apache/CONFIG ;-)
PS3 (geschrieben nach dem nötigen Schlaf, mit der Erkenntnis, daß man sich mal wieder verrannt hat ;-))
andere Erkenntnis: die doku von suphp ist mau. es ist eher eine sudoku ;-)
nicht alles ist dokumentiert, ein Blick in den Quellcode ist manchmal nötig (es wurden hier schon im Forum einige Tip(p)s gegeben...)
Was mich [ver]stört ist folgendes: (mir) nicht ganz klar ist die Funktion von suphp: ist es Ziel die php's als cgi ablaufen zu lassen? und warum sagt der Programmierer von suphp, ein mod_php[4.5] sei parallel unerwünscht?!
...
Mittlerweile sind alle Fehler, die beim PS2 gesichtet wurden, eliminiert. Nur die php-Dateien wollen weiterhin runtergeladen werden.
? Halt! Stimmt so nicht. Es gibt einige php's, die werden zum Download angeboten, bei anderen kommt Fehler500 (apache2).
Ist es Header-Problem? Das kommt mir irgendwie bekannt vor.... bin kein html/php-Codierer... ;-)
Als nächsten Lösungsansatz sehe ich nur noch die Kompilaierung von dem alten suphp, wie es unter suse9.0 noch läuft, parallel DORT zu php4... Mist, daß kann nicht die Lösung sein, alte Programme einzusetzen; aber die php's müssen endlich(!) laufen.
Hat denn keiner von den 15 Mitlesern, die hier bislang den Artikel angeklickst haben, eine Idee? 2 Tage hänge ich an dem Zeuchs, aber es ist ja nicht so, daß man nur die ganze Zeit DAS rumprobiert, nee es iss ne unnötige (Zeit kostende) Baustelle... ;-)
grüezi, Klaus (Freitag, 9.04h)
PS4: nach 20 Minuten (sorry, wenn dieser Dialog nervt, aber mich nervt das Problem noch mehr ;-) ]
suphp052 geht NICHT unter apache224 zu kompilieren (erst mit suphp 026) .merde.
in der faq von S.marschning (suphp-schöpfer) liest sich was vbon cli-modus von php, wir bräuchten die cgi-version?
ja, bitte, wie das herausfinden phpinfo geht nicht. aber kleinklausi hat eine Idee:
php -i > xxx ; dann xxx lesen. php ist als cli kompiliert. das ist wohl normal. aber wird denn eben nicht imemr gesagt/geschrieben, nicht als cgi laufen lassen? warum laufen denn bei mir meine php's nicht als cli. moment.... auf dem alten server ist php -i > xxx zwar wesentlich schlechter zu lesen..., da steht das php 4.3.11 so --enable-force-cgi-redirect compiliert wurde.... AUTSCH. ist DAS das problem? es musß als cgi kompiliert werden? warum sgt das denn keiner (wer denn?) einem?
chaos im hirn.... ;-)
PS5 (Freitag, 11.45) schade, daß hier keiner was beiträgt....
mittlerweile interessanten stoff gefunden:
PHP: PHP auf der Kommandozeile - Manual
hier infos cli versus cgi
-> es sieht so aus, als man sein php neu kompilieren muss...
(wie das vorhandene php kompiliert wurde, findet man mit php -i heraus (umlenken!)
Nachträge zur Wissenerlangung ;-)
PHP: Probleme bei der Compilierung - Manual 54.10 ist interessant!
ebenso: PHP: PHP auf der Kommandozeile - Manual (ausdrucken!) ;-)
PS6 (und Ende) Freitag 20.20
die php(5)-Skripte laufen.
(los)Lösung/(not)Lösung/Losung des Tages war: man installiere php als cgi
Ich habe ca 6 Std gebraucht, um Abhängigkeiten zu erkennen(!), sie dann aufzulösen, php_zum_widerholten_male_zu_konfiggern. uff (und das bei einem x64... ;-)
das readline-Problem war keines, obwohl configure es meinte, es war libedit: hat mich ca 2 Stunden "gekostet". es war hammerhart. (=libedit.so.... 0.0.22 musste her!!!!aus: libedit-2.9.snap20~1022-10.x86_64.rpm); ich glaube apache2 habe ich deinstallen müssen... ;-), prinzipiell sollte auf die readline-version geachtet werden. ich weiss nicht, ob das meinem 64bit opensuse10-abhöngig ist....(?)
man hat gelernt ;-)
auch wichtig bei der ganzen choose: ruhig blut. auch wenn es mal den bach runtergeht. zeitweilig war yast und der mc nicht aufzurufen. ;-)
-Immerhin haben hier 24 mitgelesen. nur hat keiner war geschrieben, ausser olle icke. hm. nunja/ninja: selbst ist der man
. ;-)-wen Einzelheiten interessieren, ich gebe gerne Auskunft.
-was ich nicht kapiere: sind die Modi cli und cgi bei der php-Kompilierung nicht gleichzeitig kompilierbar? Muss man sich für den cgi-Modus entscheiden?
-wie war das bitte noch mal mit der Sicherheit? Was sprach gegen den cgi-Modus?
Last edited by a moderator: