nicht angemeldet
Vista - Apache 2.2.15 und PHP 5.3.2 Installation/Konfiguration
Hallo,
seit den frühen Morgenstunden versuche ich auf meinem Vistasystem die genannten Komponenten auf allen Wegen zu installieren um sie auch zu konfigurieren.
Die Installation selbst stellt dabei kein Problem dar, jedoch die Konfiguration. Dabei bekomme ich keinerlei Fehlermeldungen, somit scheinen die Einträge in der httpd.conf und php.ini richtig zu sein, jedoch dauert der Aufruf einer lokalen Seite extrem lange (über 30 Sekunden) und angezeigt wird eine weise Seite mit leerem Quelltext.
Auch phpMyAdmin (3.3.4) lässt sich nicht starten, selbiges Problem wie bei den lokalen Seiten.
Da alle eine Datenbankverbindung aufbauen wollen, liegt die Vermutung nahe, das irgendwas noch fehlt und gesucht wird (dll, ini, etc.), wobei die libmysql.dll im php Verzeichnis vorhanden ist und das php-Verzeichnis in die PATH Umgebungsvariable eingebunden wurde.
Die Datenbankdaten sind korrekt eingetragen.
php.ini:
extension_dir = "C:\Program Files\php 5.3.2\ext"
extension=php_mbstring.dll
extension=php_mysql.dll
upload_max_filesize = 20M
httpd.conf:
DocumentRoot "E:/"
<Directory "E:/">
Options Indexes FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all
</Directory>
<IfModule dir_module>
DirectoryIndex index.php index.html
</IfModule>
am ende
LoadModule php5_module "C:/Program Files/php 5.3.2/php5apache2_2.dll"
PHPIniDir "C:/Program Files/php 5.3.2/"
AddHandler application/x-httpd-php .php
Verwendet jemand gleiche Komponenten auf ähnlicher Weise und/oder kann mir jemand sagen, was für einen funktionierenden Server geändert werden muss?
Danke im voraus.
MfG
Marcel Jänicke
-
Hi!
angezeigt wird eine weise Seite
Dann verinnerliche deren Inhalt;-)
Was steht denn in den Logs (error und access)?
Ist mySQL als Service installiert?
Läuft mySQL - kannst Du via Konsole darauf zugreifen?off:PP
--
"You know that place between sleep and awake, the place where you can still remember dreaming?" (Tinkerbell)
-
Was steht denn in den Logs (error und access)?
error.log
[Wed Jul 07 10:22:02 2010] [error] [client 127.0.0.1] File does not exist: E:/favicon.ico
[Wed Jul 07 10:22:04 2010] [error] [client 127.0.0.1] File does not exist: E:/favicon.icodie access.log
127.0.0.1 - - [07/Jul/2010:10:21:01 +0200] "GET /phpMyAdmin/ HTTP/1.1" 500 -
127.0.0.1 - - [07/Jul/2010:10:22:02 +0200] "GET /favicon.ico HTTP/1.1" 404 209
127.0.0.1 - - [07/Jul/2010:10:22:04 +0200] "GET /favicon.ico HTTP/1.1" 404 209Dieser Inhalt in beiden logs sollte aber kein Grund sein warum es kein Zugriff auf phpMyAdmin gibt.
Ist mySQL als Service installiert?
Ja.
Läuft mySQL - kannst Du via Konsole darauf zugreifen?
MySQL läuft und der Zugriff auf mySQL über die Konsole ist ohne Probleme möglich.
-
Hi!
Was steht denn in den Logs (error und access)?
error.log
[Wed Jul 07 10:22:02 2010] [error] [client 127.0.0.1] File does not exist: E:/favicon.ico
[Wed Jul 07 10:22:04 2010] [error] [client 127.0.0.1] File does not exist: E:/favicon.icodie access.log
127.0.0.1 - - [07/Jul/2010:10:21:01 +0200] "GET /phpMyAdmin/ HTTP/1.1" 500 -
127.0.0.1 - - [07/Jul/2010:10:22:02 +0200] "GET /favicon.ico HTTP/1.1" 404 209
127.0.0.1 - - [07/Jul/2010:10:22:04 +0200] "GET /favicon.ico HTTP/1.1" 404 209Beim Aufruf von /phpMyAdmin/ bekommst du einen 500er Fehlercode, der zu keinem Eintrag im error.log geführt haben soll? Das wäre sehr eigenartig, denn 500er sind üblicherweise nur allgemeine Meldungen in Richtung Browser, und die genaue Ursache im error.log zu finden. Übrigens kann man auch PHP ein Error-Log konfigurieren. Vielleicht ergibt das ja noch nützliche Informationen. Weiße Seiten können sich auch ergeben, wenn sich PHP mit einem Fehler beendet hat und das error_reporting oder display_error nicht gestattet hat, selbigen zu veröffentlichen.
Lo!
-
Ich habe nach deinen Vermutungen nochmals nachgeschaut und entsprechende Änderungen vorgenommen, um soviele mögliche Fehler abzufangen:
display_error = On
error_reporting = E_ALL | E_STRICT
error_log = C:\php_errors.logDennoch hat sich nichts geändert. Beim Aufruf von phpMyAdmin wird 30 Sekunden geladen und danach folgt eine weise Seite ohne Inhalt.
In der access.log entsteht jedoch jetzt allerdings kein 500er mehr sondern ein 200er (OK).
-
Hi!
Ich habe nach deinen Vermutungen nochmals nachgeschaut und entsprechende Änderungen vorgenommen, um soviele mögliche Fehler abzufangen:
PHP hatte auch Gelegenheit, die geänderten Werte zu übernehmen? Also Apache reloadet, denn du hast ja PHP als Modul eingebunden?
Dennoch hat sich nichts geändert. Beim Aufruf von phpMyAdmin wird 30 Sekunden geladen und danach folgt eine weise Seite ohne Inhalt.
Wie sieht der Aufruf von einem simplen phpinfo() aus? Wenn immer noch nichts zu sehen ist, ändert sich was, wenn du alle (verdächtigen) Extensions deaktivierst? Ergibt das Verwenden von HTTP-Header-Anzeige-Tools wie der livehttpheader-Extension im Firefox irgendwelche Erkenntnisse?
Stimmen die 30 Sekunden mit dem eingestellten Wert von max_execution_time überein?
Wenn der phpMyAdmin nicht will, versuch mal, mit einem ganz simplen Script eine Connection aufzubauen. Vom PMA hast du auch zunächst das Setup aufgerufen? (Ich weiß grad nicht, ob er das von selbst startet, wenn noch keine ordentliche Konfigurationsdatei vorliegt und man das PMA-Hauptverzeichnis aufruft.)
Lo!
-
PHP hatte auch Gelegenheit, die geänderten Werte zu übernehmen? Also Apache reloadet, denn du hast ja PHP als Modul eingebunden?
Ja, ein Restart von Apache hat stattgefunden.
Wie sieht der Aufruf von einem simplen phpinfo() aus? Wenn immer noch nichts zu sehen ist, ändert sich was, wenn du alle (verdächtigen) Extensions deaktivierst? Ergibt das Verwenden von HTTP-Header-Anzeige-Tools wie der livehttpheader-Extension im Firefox irgendwelche Erkenntnisse?
Ein Aufruf mit einer phpinfo() bringt in der von mir erstellten error_log auf C:/php_errors.log einen Fehler
[07-Jul-2010 11:46:41] PHP Warning: phpinfo(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Paris' for '2.0/DST' instead in E:\test.php on line 2
In der Info stehen aber alle Daten richtig drinn, es sind nur die Extension aufgeführt die ich auch aktiviert habe (mbstring und mysql), die richtige php.ini wird auch verwendet.
Live HTTP-Header bringt keine merkwürdigkeiten, für ihn scheint alles ok, dennoch weise Seite:
HTTP/1.1 200 OK
Date: Wed, 07 Jul 2010 09:48:30 GMT
Server: Apache/2.2.15 (Win32) PHP/5.3.2
X-Powered-By: PHP/5.3.2Stimmen die 30 Sekunden mit dem eingestellten Wert von max_execution_time überein?
Dort stehen 30 Sekunden, jodoch hatte ich jetzt gescchaut und dabei waren es 57 Sekunden, also könnte es vom max_input_time = 60 oder vom default_socket_timeout = 60 kommen.
Ein einfacher Verbindungsaufbau schlägt fehl:
PHP Warning: mysql_connect(): Ein Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat, oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host nicht reagiert hat.
Die Konfiguration für myPhpAdmin stimmt aber, denn wenn ich Apache 2.0.63 und php 5.2.6 dazu laufen habe, läuft es super.
MfG
Marcel-
Hi!
Ein Aufruf mit einer phpinfo() bringt in der von mir erstellten error_log auf C:/php_errors.log einen Fehler
[07-Jul-2010 11:46:41] PHP Warning: phpinfo(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Paris' for '2.0/DST' instead in E:\test.php on line 2
Die Meldung ist geschenkt. Trotzdem solltest du noch in der php.ini den Wert für date.timezone versorgen, damit dieser Meldung und Warnungen beim Gebrauch der Datums- und Zeit-Funktionen die Grundlage entzogen ist.
In der Info stehen aber alle Daten richtig drinn, es sind nur die Extension aufgeführt die ich auch aktiviert habe (mbstring und mysql), die richtige php.ini wird auch verwendet.
phpinfo() läuft also problemlos inklusiv der eingebundenen Extensions. Soweit so gut. Und libmysql.dll wird für PHP ab Version 5.3 nicht mehr benötigt.
Stimmen die 30 Sekunden mit dem eingestellten Wert von max_execution_time überein?
Dort stehen 30 Sekunden, jodoch hatte ich jetzt gescchaut und dabei waren es 57 Sekunden, also könnte es vom max_input_time = 60 oder vom default_socket_timeout = 60 kommen.Dann wohl eher mysql.connect_timeout.
max_execution_time zählt nur die effektiv verbratene Zeit, Wartezeiten zählen nicht dazu, weshalb das sicher nicht die Ursache ist.PHP Warning: mysql_connect(): Ein Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat, oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host nicht reagiert hat.
Nun wird es interessant.
Die Konfiguration für myPhpAdmin stimmt aber, denn wenn ich Apache 2.0.63 und php 5.2.6 dazu laufen habe, läuft es super.
Und das läuft alles auf der selben Maschine wie das 5.3er PHP, so dass die Netzwerkkonfiguration (Firewall?) als Ursache ausgeschlossen werden kann?
Lo!
-
Hi,
ja, das läuft alles auf einer Maschine. Ich habe 2 Apache, einmal die 2.0.x und die 2.2.x. Beide arbeiten mit unterschiedlichen php Versionen wie ich schon erwähnte.
So wollte ich von der einen Konfiguration auf die neue Wechseln, was bis jetzt leider noch nicht geglückt ist.
Und libmysql.dll wird für PHP ab Version 5.3 nicht mehr benötigt.
In nahezu fast allen Beschreibungen die man findet ist immer wieder davon die Rede, die lbmysql zu verwenden, weshalb auch in die PATH Umgebungsvariable der php Ordner eingebunden werden muss. Damit wär dies auch nicht notwendig.
Gruß
Marcel-
Hi!
ja, das läuft alles auf einer Maschine. Ich habe 2 Apache, einmal die 2.0.x und die 2.2.x. Beide arbeiten mit unterschiedlichen php Versionen wie ich schon erwähnte.
Noch eigenartiger. Auf Windows-Maschinen kommt, wenn ich mich nicht irre, nur der Weg über den Netzwerkport 3306 in Frage. Unter Unix kann man sich noch mit einem falsch konfigurierten Socket in den Fuß schießen.
Ich bin mit meinen Ideen vorläufig am Ende und überlege mal laut vor mich hin: Was führt zu einem Timeout und was wird sofort wegen eines Fehlers abgebrochen?
- falscher Zielmaschinenname? localhost sollte reichen, und der müsste bei der Alt-Installation auch so lauten. Ein nicht aufzulösender Name sollte eine entsprechende Meldung und keinen Timeout bringen.
- falscher Port? Schon eher ein Kandidat für einen Timeout.
- Unzureichende Berechtigung ist ausgeschlossen, die würde sofort mit einer Meldung geahndet werden.
- Firewall hatte ich schon nebenbei fallen lassen. Nicht dass da eine solche dem neuen Programm den Zugriff verbietet und ansonsten bei nicht erlaubten Versuchen schweigt.
Und libmysql.dll wird für PHP ab Version 5.3 nicht mehr benötigt.
In nahezu fast allen Beschreibungen die man findet ist immer wieder davon die Rede, die lbmysql zu verwenden, weshalb auch in die PATH Umgebungsvariable der php Ordner eingebunden werden muss. Damit wär dies auch nicht notwendig.Das war von 5.0 bis <5.3 auch notwendig, aber mit dem neu hinzugekommenen mysqlnd erübrigt sich diese Notwendigkeit: "MySQL Native Driver is a replacement for the MySQL Client Library (libmysql). MySQL Native Driver is part of the official PHP sources as of PHP 5.3.0." Vor 5.0 war die MySQL-Bibliothek auch fester Bestandteil PHPs, doch wegen lizenzrechtlicher Probleme wurde die Kopplung zwischen PHP und der libmysql gelöst, so dass man sie für 5.0 bis 5.2 händisch hinzufügen musst.
Lo!
-
Es ist wirklich merkwürdig, ich kann zwar mit der älteren Konfiguration arbeiten und werde dies wohl auch noch länger tun, aber irgendwo muss sich der Grund befinden für das Verhalten.
Der Port ist 3306, das Ziel localhost, Firewall ist deaktiviert wobei sie auch nur den Mysql Server blocken dürfte und da dieser unter der php5.2.6 funktoiniert bei aktiver Firewall, sollte das auch passen, wie der Rest auch.
Ich hoffe es findet sich noch das Problem.
Besten Dank für die Ratschläge und die Nerven ;)
MfG
Marcel Jänicke-
Hallo,
nach weiterer, längerer Recherche bin ich nun zu einer Lösung gekommen, die vorerst gilt, dazu folgender Link:
http://bugs.php.net/bug.php?id=45150
Das auskommentieren des Einrags ::1 zieht sicher noch weitere Nachteile mit sich,dennoch vorerst ausreichend.
Grüße
Marcel Jänicke-
Hi!
nach weiterer, längerer Recherche bin ich nun zu einer Lösung gekommen, die vorerst gilt, dazu folgender Link:
http://bugs.php.net/bug.php?id=45150
Das auskommentieren des Einrags ::1 zieht sicher noch weitere Nachteile mit sich,dennoch vorerst ausreichend.Aha, also doch ein Netzwerkproblem. ::1 ist das IPv6-Äquivalent zur IPv4-Adresse für localhost: 127.0.0.1. localhost wurde also nach ::1 aufgelöst, was zu einer Verwendung von IPv6 führte und eine Verbindung zum MySQL-Server verhinderte. Dein MySQL ist entweder noch nicht IPv6-fähig oder nicht entsprechend konfiguriert.
Nachteile wirst du von der Deaktivierung keine haben, wenn du nicht explizit mit IPv6 arbeiten willst. Heutzutage übliche Software sollte eigentlich auch dann arbeiten, wenn es nur IPv4 vorfindet.
Lo!
-
-
-
-
-
-
-
-
-
-