phpinfo()

[Marc]

Hallo Leute

Ich wollte bei meinem Provider nachschauen wie die Php.ini aussieht.
In allen Lektüren die ich habe steht drin

<?php
   phpinfo();
?>

Aber hier bekomme ich nur die Fehlermeldung:

Warning: phpinfo() has been disabled for security reasons. in /customer/www/natko/natkotest/atest.php on line 3

Das heißt doch, das ich nicht einmal diese auslesen darf. Oder?

Kann mir bitte jemand mal erklären wie ich sonst vielleicht an die Daten komme.

Danke Marc

[Cheatah]

Hi,

Ich wollte bei meinem Provider nachschauen wie die Php.ini aussieht.

erlaubt Dir Dein Provider das? Es ist _sein_ Server.

Warning: phpinfo() has been disabled for security reasons. in /customer/www/natko/natkotest/atest.php on line 3

Das heißt doch, das ich nicht einmal diese auslesen darf. Oder?

"Nicht einmal" ist gut - da steht wahnsinnig viel an Infos drin. Aber ja, das heißt, dass Du phpinfo() nicht ausführen darfst.

Kann mir bitte jemand mal erklären wie ich sonst vielleicht an die Daten komme.

Frage Deinen Provider. Am ehesten wird er Dir zu spezifischen Fragen Auskunft geben.

Cheatah

[Marc]

Hallo

erlaubt Dir Dein Provider das? Es ist _sein_ Server.

Ja klar. Ich wollte nur die Einstellung lesen und nicht verändern.

"Nicht einmal" ist gut - da steht wahnsinnig viel an Infos drin.

Aber ja, das heißt, dass Du phpinfo() nicht ausführen darfst.

Ich habe seit Tagen das Problem, das ich keine Upload auf den Server bekomme. Erst dachte ich, das es ein Fehler im Script sei. Habe alles ausprobiert, und auch bei fertigen Scripts die ich aus dem Netz habe immer der selbe Fehler. Keine Schreibberechtigung.

Frage Deinen Provider. Am ehesten wird er Dir zu spezifischen Fragen Auskunft geben.

Habe ich getan. Die suchen seit Tagen den "FEHLER" finden ihn aber nicht. Jetzt wollte ich halt mal selbst "nachschauen" und falls ich ihn finden sollte denen einfach einen Hinweis geben.

Ach ja die Schreibberechtigung soll angeblich i.O. sein.

Marc

[Andreas Cloos]

Hallo Zusammen,

Ich habe seit Tagen das Problem, das ich keine Upload auf den Server bekomme. Erst dachte ich, das es ein Fehler im Script sei. Habe alles ausprobiert, und auch bei fertigen Scripts die ich aus dem Netz habe immer der selbe Fehler. Keine Schreibberechtigung.

Was versuchst Du denn? Mit php eine Datei anlegen oder ändern?

Keine Ahnung, wie es genau geht, aber kann es sein, daß für das entsprechende Verzeichnis nur ungenügende Schreibrechte gesetzt sind? Die kannst Du mit Deinem FTP-Client erkennen und wohl auch ändern (frag mich jetzt nicht, wie - das Problem hatte ich bisher noch nicht, da mein eigener Webspace eh kein PHP kann und Schreiboperationen bisher für mich kein Thema waren).

[Cheatah]

Hi,

Keine Ahnung, wie es genau geht, aber kann es sein, daß für das entsprechende Verzeichnis nur ungenügende Schreibrechte gesetzt sind?

sowas vermute ich auch. Das hat dann allerdings mit PHP nichts zu tun - es sind die Rechte des Servers (genauer: seiner Worker-Prozesse), denen die Schreibrechte fehlen. Ebenfalls verantwortlich sein könnte eine zu restriktiv eingestellte quota.

Die kannst Du mit Deinem FTP-Client erkennen und wohl auch ändern

Man beachte bitte, dass per FTP in aller Regel ein anderer Username verwendet wird, als von einem HTTP-Server. Wenn man per FTP schreiben kann heißt das also noch lange nicht, dass es auch mit PHP gehen "müsste".

Versuch doch mal - falls Systemaufrufe erlaubt sind - das Kommando ls -al abzusetzen, und sieh Dir dessen Rückgabe als text/plain an. Dann noch mit der User-Angabe eines ps auxw|grep httpd vergleichen. Ach so, ich setze hier natürlich ein Unix voraus.

Cheatah

[Fabian Transchel]

Hi Cheatah

Versuch doch mal - falls Systemaufrufe erlaubt sind - das Kommando ls -al abzusetzen, und sieh Dir dessen Rückgabe als text/plain an. Dann noch mit der User-Angabe eines ps auxw|grep httpd vergleichen. Ach so, ich setze hier natürlich ein Unix voraus.

Warum sagst du das extra, glaubst du ernsthaft, dass "ps auxw|grep httpd" unter einer anderen Plattform funktioniert? Und glaubst du ernsthaft, dass Marc's Provider so dämlich ist, eine bugverseuchte PHP-Version auf einem bugverseuchten OS zu fahren?

Wenn dem so ist (*g* das würde man in der PHP.ini ja sehen können...), dann würde ich an Marcs Stelle nur noch zum Kündigen anrufen ;-)

Fabian
[ja ne, nicht so allzu ernst nehmen bitte. danke. :P]

[Cheatah]

Hi,

Ach so, ich setze hier natürlich ein Unix voraus.
Warum sagst du das extra, glaubst du ernsthaft, dass "ps auxw|grep httpd" unter einer anderen Plattform funktioniert?

nein; sondern weil ich nicht weiß, ob jemand anders, der dies versucht, sich dessen bewusst ist :-)

Und glaubst du ernsthaft, dass Marc's Provider so dämlich ist, eine bugverseuchte PHP-Version auf einem bugverseuchten OS zu fahren?

Er ist zumindest zu dämlich[1] herauszufinden, warum aus einem PHP-Script heraus nicht geschrieben werden kann, von daher möchte ich das nicht ausschließen ;-)

Nein, ich gehe in einem akuten Anfall chronischen Optimismus' regelmäßig davon aus, dass ab und zu auch mal jemand das Archiv verwendet. Es lässt sich schwer abschätzen, was für ein System diese Person haben wird.

Cheatah

[1] Disclaimer: _Du_ hast mit diesem Begriff angefangen, nicht ich *g*

[Fabian Transchel]

Hi Cheatah,

Ach so, ich setze hier natürlich ein Unix voraus.
Warum sagst du das extra, glaubst du ernsthaft, dass "ps auxw|grep httpd" unter einer anderen Plattform funktioniert?

nein; sondern weil ich nicht weiß, ob jemand anders, der dies versucht, sich dessen bewusst ist :-)

Na gut, es wäre mir eine Freude gewesen ihm seine Fehlermeldung zu erläutern. Das heißt, falls system(); überhaupt erlaubt ist >;)

Und glaubst du ernsthaft, dass Marc's Provider so dämlich ist, eine bugverseuchte PHP-Version auf einem bugverseuchten OS zu fahren?
Er ist zumindest zu dämlich[1] herauszufinden, warum aus einem PHP-Script heraus nicht geschrieben werden kann, von daher möchte ich das nicht ausschließen ;-)

Und? Microsoft ist zu dämlich um Software zu produzieren. (Okay, der Vergleich hinkt, aber das muste ich einfach sagen *lol*)

Nein, ich gehe in einem akuten Anfall chronischen Optimismus' regelmäßig davon aus, dass ab und zu auch mal jemand das Archiv verwendet. Es lässt sich schwer abschätzen, was für ein System diese Person haben wird.

Ja. Völlig unbegründet. Aber lass man, die nächste Zwei-Frames-Frage zerstört diesen Optimismus wieder... ;-)

[1] Disclaimer: _Du_ hast mit diesem Begriff angefangen, nicht ich *g*

Und? Was hätte ich sonst sagen können? "suboptimal qualifiziert"? *muhaha*

Fabian

[Cheatah]

Hi,

Na gut, es wäre mir eine Freude gewesen ihm seine Fehlermeldung zu erläutern.

na sowas, Dir auch? ;-)

Und? Microsoft ist zu dämlich um Software zu produzieren. (Okay, der Vergleich hinkt, aber das muste ich einfach sagen *lol*)

Argl... :-)

[1] Disclaimer: _Du_ hast mit diesem Begriff angefangen, nicht ich *g*
Und? Was hätte ich sonst sagen können? "suboptimal qualifiziert"? *muhaha*

"Mental herausgefordert" ;-)

Cheatah

[Thomas Schmieder]

Hall Marc,

verrsuch doch wenigstens mal die version abzufragen.

echo phpversion();

wenn das dann geht. Und wenn es eine zwischen 4.0.6 und 4.2.3 ist, dann frag genauer nach. da gab es einen Bug im Envirenmentbereich des Scriptes, sodass File-Infomationen, Postvariablen usw. bei bestimmter kombinierter Verwewndung verstümmelt wurden.

Gibts hier einige Threads drüber.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Marc]

Hallo Tom,

verrsuch doch wenigstens mal die version abzufragen.

echo phpversion();

wenn das dann geht. Und wenn es eine zwischen 4.0.6 und 4.2.3 ist, dann frag genauer nach. da gab es einen Bug im Envirenmentbereich des Scriptes, sodass File-Infomationen, Postvariablen usw. bei bestimmter kombinierter Verwewndung verstümmelt wurden.

Version:4.0.3pl1

Also kein Bug ?!?!

Ich krieg die Kriese.

Marc

[Fabian Transchel]

Hi Marc,

Ich krieg die Kriese.

<philosophie> Nein, denn wer Krise nicht schreiben kann, der hat auch keine >;P </philosophie>

Aber im Ernst, was möchtest denn du aus PHPinfo(); erfahren?
Wenn du das mal erzählst kann man eventuell auch über andere Wege an die Infos kommen.

Du könntest zum Beispiel mal

print_r($_ENV);
print_r($_SERVER);
print_r($_PHP);
print_r($_POST);
print_r($_GET);
print_r($_SESSION);
print_r($_REQUEST);

anfangen, denn das wird dein Provider kaum gesperrt haben.

BTW: Warum deaktiviert jemand phpinfo()? Aus Angst, dass man etwaige Sicherheitsrelevanzen feststellt?

Fabian

[Marc in der KRISE]

Hi Farbian,

Ich krieg die Kriese.
<philosophie> Nein, denn wer Krise nicht schreiben kann, der hat auch keine >;P </philosophie>

Richtig.

Warum ich die phpinfo() lesen wollte habe ich in einem anderen Posting schon beantwortet. Mein Provider ist nicht in der Lage den Sch... Fehler zu finden, damit ich endlich Uploads fahren kann.

Marc

[xwolf]

Hi,

Version:4.0.3pl1

Also kein Bug ?!?!

Doch!
Wenn der Typ bei dieser Version file-upload nicht disabled hat, kann man den Server knacken >:)
Der sollte dringend auf eine neue Version updaten.
Gruende in Detail siehe de.php.net .

Vielleicht hat ja jemand anders schon den Bug genutzt und
hat danach -damit niemand seinen neuen Slave-rechner missnachkonfiguriert- die Lücke duch abschalten der File-Upload-Funktion
wieder abgeschaltet...

In php.ini sind die Zeilen
 file_uploads = Off|On
 upload_max_filesize = 2M
interessant..

Ciao,
  Wolfgang

P.S.: Und es gibt noch Leute, die behaupten, PHP ist sicherer als CGI mit einer anderen Sprache >:)

[Fabian Transchel]

Hi xwolf,

P.S.: Und es gibt noch Leute, die behaupten, PHP ist sicherer als CGI mit einer anderen Sprache >:)

Ist es auch. - Wenn man weiß, was man tut.
Nein, ich will hier keine Diskussion darüber führen, da können wir uns ewig streiten.
Meiner Meinung nach ist PHP bloß deswegen Sicherheitsanfälliger weil der Newbee-Programmiereranteil viel größer ist als bei in Perl oder gar in anderen Sprachen geschriebenen CGIs.

Fabian

[xwolf]

Hi,

Meiner Meinung nach ist PHP bloß deswegen Sicherheitsanfälliger weil der Newbee-Programmiereranteil viel größer ist als bei in Perl oder gar in anderen Sprachen geschriebenen CGIs.

Sehe ich nicht so.
IMHO ist *keine* Sprache sicher oder unsicher.

Wer sauber programmiert und nicht einfach alles ohne Sinn und Verstand hinklatscht und dabei beruecksichtigt das man sich in einer Multiuser-Umgebung befinden kann, schreibt auch in der Regel sichere Programme.

Wer dagegen nur mal schnell irgendwas hinrotzt oder sich auf WYSIWYG-Editoren verlaesst, weder Kommentare noch irgend eine Struktur nutzt, wird in sehr haeufig Sicherheitslücken machen.

Das geht bei jeder Sprache so. Auch mit Sprachen, die laut theoretischer Informatik "abgeschlossen" sind. Der Faktor Mensch spielt halt mit. Der Filezugriff mag ja informatiktechnisch absolut sicher sein; Was nutzt dies aber, wenn das Skript die File
aus Sicherheitsgruenden aber nicht lesen koennen soll? >:)

Ciao,
  Wolfgang

[Fabian Transchel]

Hi xwolf,

Sehe ich nicht so.
IMHO ist *keine* Sprache sicher oder unsicher.

Wer sauber programmiert und nicht einfach alles ohne Sinn und Verstand hinklatscht und dabei beruecksichtigt das man sich in einer Multiuser-Umgebung befinden kann, schreibt auch in der Regel sichere Programme.

Wer dagegen nur mal schnell irgendwas hinrotzt oder sich auf WYSIWYG-Editoren verlaesst, weder Kommentare noch irgend eine Struktur nutzt, wird in sehr haeufig Sicherheitslücken machen.

Das geht bei jeder Sprache so. Auch mit Sprachen, die laut theoretischer Informatik "abgeschlossen" sind. Der Faktor Mensch spielt halt mit. Der Filezugriff mag ja informatiktechnisch absolut sicher sein; Was nutzt dies aber, wenn das Skript die File
aus Sicherheitsgruenden aber nicht lesen koennen soll? >:)

Ausnahmsweise, nur um gesagt zu haben, dass ich es auch so meinte nicht mehr als: ACK.

Fabian

[Marc]

Hi, Xwolf

Version:4.0.3pl1

Also kein Bug ?!?!

Doch!

Danke für die Info.

Ich werde morgen den Provider anrufen und ihn das mal so weitergeben.

Nochmal Danke für deine Mühe.

Marc

[Christoph Schnauß]

hallo Marc,

wenn dein Provider tatsächlich nur augenblickliche Probleme hat und eine Unterstützung von deiner Seite begrüßt, kannst du es ja auch mal "aushilfsweise" mit einer anderen serverseitigen Sprache versauchen. Fast alles, was dir phpinfo liefern kann, läßt sich auch mit PERL auslesen - naja, nicht unbedingt die PHP-spezifischen Sachen, aber Systempfade, Umgebungsvariablen etc. kriegst du auch mit PERL geliefert.

Rücksprachen mit dem Provider sind aber immer sehr sinnvoll

Grüße aus Berlin

Christoph S.

[Marc]

hallo Christoph

wenn dein Provider tatsächlich nur augenblickliche Probleme hat

Nein das Prob scheint noch nie aufgetacht zu sein, weil auf dem Server nur private HP liegen, die PHP nicht verwenden.(Aussage des Provider). Auch mit anderen "Sprachen" außer PHP habe ich es versucht. Die Dateien die ich uploaden will kommen nicht auf dem Server an.

Marc

[Christoph Schnauß]

hallo Cheatah,

Warning: phpinfo() has been disabled for security reasons.
Das heißt doch, das ich nicht einmal diese auslesen darf. Oder?
"Nicht einmal" ist gut - da steht wahnsinnig viel an Infos drin. Aber ja, das heißt, dass Du phpinfo() nicht ausführen darfst.

Manchmal bringst du mich ja direkt auf Fragen, von denen ich nicht glaubte, sie je stellen zu können. Hast du unter Umständen eine Erklärung, _wie_ man phpinfo verbieten kann?

Sonst: eben weil phpinfo derart viel Informationen liefert, ist mir das durchaus verständlich, wenn ein Provider nicht möchte, daß Systempfade, Umgebungsvariablen und ähnliches ausgelesen werden können

Frage Deinen Provider. Am ehesten wird er Dir zu spezifischen Fragen Auskunft geben.

Es ist eh Sache des Providers, zu entscheiden, was er für zulässig hält. Normalerweise finden sich aber Hinweise für das, was zulässig, und das, was eben nicht zulässig ist, in der entsprechenden "Help"-Sektion des Providers.

Grüße aus Berlin

Christoph S.

[Cheatah]

Hi,

Hast du unter Umständen eine Erklärung, _wie_ man phpinfo verbieten kann?

nein. Ich nehme aber an, dass sich das in der php.ini finden lässt ;-)

Cheatah

[xwolf]

Hi,

Manchmal bringst du mich ja direkt auf Fragen, von denen ich nicht glaubte, sie je stellen zu können. Hast du unter Umständen eine Erklärung, _wie_ man phpinfo verbieten kann?

"disable_functions=phpinfo" ?

Sonst: eben weil phpinfo derart viel Informationen liefert, ist mir das durchaus verständlich, wenn ein Provider nicht möchte, daß Systempfade, Umgebungsvariablen und ähnliches ausgelesen werden können

Man kann phpinfo() zulassen, aber die Environmentinfo und Settings dennoch weglassen...
....sofern man kein ClickiAdmin ist, der es als höchste Kunst sieht, Yast zu bedienen >:)

Du musst in deiner apachectl in der Zeile wo der Path zum HTTPD
definiert ist, ein "env -i" einfuegen.
Also z.B.:

HTTPD="/usr/bin/env -i /local/apache-1.3.27/bin/httpd"

Siehe "man env" für mehr Infos.

Ciao,
  Wolfgang

[Christoph Schnauß]

hi Wofgang,

"disable_functions=phpinfo" ?

öhm ... nö. Jedenfalls nicht in php.ini :-( Habbich mal eben durchprobiert, sagt nix. Und in der httpd.conf hat das nix zu suchen

Man kann phpinfo() zulassen, aber die Environmentinfo und Settings dennoch weglassen...

Das sollte mit variables_order = "EGPCS" (bzw. anderer Wert) oder register_argc_argv = On/Off und ähnlichem Kram möglich sein; jedenfalls nach diversen Anleitungen. Tut es bei mir jedoch grade nicht

....sofern man kein ClickiAdmin ist, der es als höchste Kunst sieht, Yast zu bedienen >:)

tststs, hab ich mir wirklich so einen miserablen Ruf erworben?

Du musst in deiner apachectl in der Zeile wo der Path zum HTTPD
definiert ist, ein "env -i" einfuegen.

hm, apachectl ist ne Idee

Siehe "man env" für mehr Infos.

Ehrlich gesagt, da hab ich eigentümlicherweise noch nie reingeschaut. Ich habe fleißig die Apache- und PHP-Dokumentationen studiert und bin gar nicht auf die Idee gekommen, in den manual pages rumzukrabbeln.

Andrerseits: was mache ich nu, wenn ich grade WAMP laufen habe, wo es weder man pages noch apachectl gibt?

Grüße aus Berlin

Christoph S.

[Fabian Transchel]

Hi Christoph,

"disable_functions=phpinfo" ?
öhm ... nö. Jedenfalls nicht in php.ini :-( Habbich mal eben durchprobiert, sagt nix. Und in der httpd.conf hat das nix zu suchen

Mhh, wie genau hast du das denn gemacht? Ich dachte dafür ist das da?

Man kann phpinfo() zulassen, aber die Environmentinfo und Settings dennoch weglassen...
Das sollte mit variables_order = "EGPCS" (bzw. anderer Wert) oder register_argc_argv = On/Off und ähnlichem Kram möglich sein; jedenfalls nach diversen Anleitungen. Tut es bei mir jedoch grade nicht

Was hast du für einen Server...? >;P

....sofern man kein ClickiAdmin ist, der es als höchste Kunst sieht, Yast zu bedienen >:)
tststs, hab ich mir wirklich so einen miserablen Ruf erworben?

Nein, aber andere...

Andrerseits: was mache ich nu, wenn ich grade WAMP laufen habe, wo es weder man pages noch apachectl gibt?

Ruf den Super-"Freie Software unter Windoof"-Bio-Support an ;-)

Fabian

[xwolf]

Hi.

"disable_functions=phpinfo" ?
öhm ... nö. Jedenfalls nicht in php.ini :-( Habbich mal eben

So steht das bei mir aber in der default-php.in als Möglichkeit drin!
(Aktuelle PHP-Version)

....sofern man kein ClickiAdmin ist, der es als höchste Kunst sieht, Yast zu bedienen >:)
tststs, hab ich mir wirklich so einen miserablen Ruf erworben?

Ich meinte nicht dich, sondern allgemein!

Du musst in deiner apachectl in der Zeile wo der Path zum HTTPD
definiert ist, ein "env -i" einfuegen.
hm, apachectl ist ne Idee

Idee ist gut...
ich hab da einige Stunden nach gesucht um das problem damals zu lösen.
Denn dokumentiert findest du das leider nur schwer.

Andrerseits: was mache ich nu, wenn ich grade WAMP laufen habe, wo es weder man pages noch apachectl gibt?

Auch beim WAMP ist apachectl dabei. Man muss nur gut suchen...

Bei den Apacheversionen, die von BSD, Suse, RedHad und co ausgeliefert
und installiert werden sind alle möglichen Files über das ganze System verstreut.
Und jeder macht es woanders!
Einig sind sich die Distributoren nur darin, dass keiner sich daran hält, wie es Apache selbst empfiehlt (naemlich alles unter /usr/local/apache_XXXX zu legen).

Diese Liste hat mich bestimmt 3 Jahre meines Lebens gekostet:
http://rzsunhome.rrze.uni-erlangen.de/~unrzc9/perl_apache.txt

Um es so zu sagen: Real Sysadadmins are using make!

Ciao,
  Wolfgang

[Christoph Schnauß]

hi Wolfgang,

"disable_functions=phpinfo" ?
öhm ... nö. Jedenfalls nicht in php.ini :-(
So steht das bei mir aber in der default-php.in als Möglichkeit drin! (Aktuelle PHP-Version)

Unter "aktuelle PHP-Version" verstehe ich zur Zeit 4.3  -  die habe ich auf allen mir zur Verfügung stehenden Systemen (Win98SE, WinXP, FreeBSD current, SuSE LINUX 7.3/8.1, RedHat 8.0), allerdings hab ich im Moment nur auf FreeBSD nachgeschaut

tststs, hab ich mir wirklich so einen miserablen Ruf erworben?
Ich meinte nicht dich, sondern allgemein!

schon gut ;-)

hm, apachectl ist ne Idee
Idee ist gut...
ich hab da einige Stunden nach gesucht um das problem damals zu lösen. Denn dokumentiert findest du das leider nur schwer.

Ich bin grade noch dabei, daran rumzuspielen. Normalerweise benutze ich meine eigenen Startscripts, und die "default"-Scripts nehme ich nur zum Vergleich bzw. als "Backup", falls ich mich dabei irgendwie schwerwiegend verirre

Auch beim WAMP ist apachectl dabei. Man muss nur gut suchen...

Tut mir leid, wenn ich dir widersprechen muß. Bei mir (WinXP mit SP1, Apache 2.0.43) ist es nicht dabei, nicht einmal als registry-Eintrag. Es gibt lediglich im manual eine apachectl.html.
Das ist auch verständlich, weil apachectl ja "nur" das Startscript ist, und in Win brauchts eigentlich kein solches Script.

Diese Liste hat mich bestimmt 3 Jahre meines Lebens gekostet:
http://rzsunhome.rrze.uni-erlangen.de/~unrzc9/perl_apache.txt

oh. Beeindruckend. Aber wenn du den Hinweis nicht übelnimmst: die Liste ist trotz der drei Jahre nicht ganz aktuell und auch nicht ganz vollständig (zumindest, was deine Angaben zur SuSE und zu FreeBSD angeht)

Um es so zu sagen: Real Sysadadmins are using make!

"... are using
     $ ./configure --prefix=PREFIX
     $ make"
wolltest du schreiben, gelle?

Grüße aus Berlin

Christoph S.

[xwolf]

Hi,

Unter "aktuelle PHP-Version" verstehe ich zur Zeit 4.3  -  die habe ich auf allen mir zur Verfügung stehenden Systemen (Win98SE, WinXP, FreeBSD current, SuSE LINUX 7.3/8.1, RedHat 8.0), allerdings hab ich im Moment nur auf FreeBSD nachgeschaut

Hm....Seltsam; ich hab meine aber auch nicht von einen Distributor, sondern direkt von php.net

Auch beim WAMP ist apachectl dabei. Man muss nur gut suchen...
Tut mir leid, wenn ich dir widersprechen muß. Bei mir (WinXP mit SP1, Apache 2.0.43) ist es nicht dabei, nicht einmal als

Hm...ok, ueberzeugt;

Ich geb halt zu, dass ich das selbst nie nutz.

Diese Liste hat mich bestimmt 3 Jahre meines Lebens gekostet:
http://rzsunhome.rrze.uni-erlangen.de/~unrzc9/perl_apache.txt
oh. Beeindruckend. Aber wenn du den Hinweis nicht übelnimmst: die

Steht auch bei: Stand April 2001

Um es so zu sagen: Real Sysadadmins are using make!
     "... are using
     $ ./configure --prefix=PREFIX
     $ make"
wolltest du schreiben, gelle?

Ja :))

Und vorallem bei Apache:
 ...
 --enable-suxec \  ...

Es gibt wirklich einige Distributoren, die machen das nicht per
Default....

openssl, mod_ssl, mod_fastcgi, libpng, libgd, mod_php und mod_perl
von Hand zu installieren ist zwar aufwendig, aber dann ist es
wenigstens richtig...

Ciao,
  Wolfgang

[MudGuard]

Hi,

"disable_functions=phpinfo" ?
öhm ... nö. Jedenfalls nicht in php.ini :-( Habbich mal eben durchprobiert, sagt nix. Und in der httpd.conf hat das nix zu suchen

mod_php? Dann nicht vergessen, den Apache anzuhalten und neuzustarten bei Änderungen in der php.ini ...

cu,
Andreas