Plesk "Seite kann nicht angezeigt werden"

triumvirat

Registered User
Hallo zusammen,

ich habe ein "Nadel im Heuhaufen" - Problem. Gespickt mit vagen Vermutungen zum Lösungsansatz, heisse Mischung.

Ausgangslage:
RootServer bei Schlund + Partner mit Plesk Admin Konsole.
Auf dem Server läuft eine LAMP Anwendung. Alles einwandfrei. Ab und zu, völlig unkontrolliert erscheint bei den Redakteuren des Systems beim absenden von Formularen ein freundliches "Seite kann nicht angezeigt werden" nach dem absenden des Formulars innerhalb von ein paar Millisekunden. Im Error Log des Apache steht nix und im error_log des Virtual Hosts steht auch nix drin. Die anfrage wir so schnell mit der oben genannten Fehlermeldung quittiert, dass es so scheint, als wenn die Anfrage gar nicht an dem Server mehr ankommt. Offensichtlich passiert das aber nur, wenn sich ein anderer Kunde von mir innerhalb des Webmailers von Horde (ist ja automatisch bei Plesk drinn) eingeloggt hat. Scheinbar fühlt sich der Server nicht mehr für meine Virtual Host Domain zuständig.

Bitte sagt mir, was Ihr für Infos braucht, um mir helfen zu können.
Ich weiss nämlich keinen Rat mehr, wie ich der Sache auf den Grund gehen soll.

Dankeschön vorab
mfg Ekki
 
<MOD>
Bitte nicht puschen.
Wer nicht die Zeit/Geduld hat auf Antwort zu warten, greift zum Telefon oder sucht im Chat!
</MOD>

triumvirat said:
Auf dem Server läuft eine LAMP Anwendung.
Welche?

beim absenden von Formularen ein freundliches "Seite kann nicht angezeigt werden"
Bringt ein Reload dann etwas?

Im Error Log des Apache steht nix
Hast Du auch im access_log nachgesehen ob der entsprechende Request dort verzeichnet ist?

Offensichtlich passiert das aber nur, wenn sich ein anderer Kunde von mir innerhalb des Webmailers von Horde (ist ja automatisch bei Plesk drinn) eingeloggt hat.
Gibt es für die Vermutung einen Beweis oder sonst eine Grundlage?
Denn Grundsätzlich würde ich hier einen Zusammenhang ausschließen.

huschi.
 
Hallo Huschi,

nun, die LAMP Anwendung ist selbst programmiert. Ich erzeuge ein einfaches Formular mit Quickform und will das dann per Submit an den Server übertragen. Wenn "Die seite kann nicht angezeigt werden" auftaucht, dann bringt der Reload nix. Im access_log ist der Request auch nicht verzeichnet. Wie gesagt die Fehlermeldung des Browsers kommt innerhalb von 2 Millisekunden und wird nicht vom Server beantwortet, jedenfalls nicht offensichtlich.

Allerdings gibt es ein weiteres Phenomen, welches mich vermuten lässt, dass es mit dem Webmailer zu tun hat.

Ab und zu bekomme ich auch eine ganz komische Fehlermeldung:
Code:
Warning: main(HTML/QuickForm.php): failed to open stream: No such file or directory in /home/httpd/vhosts/xxx.de/httpsdocs/xxx/modules/workshop/inc/workshopform.class.php on line 3

Fatal error: main(): Failed opening required 'HTML/QuickForm.php' (include_path='/usr/share/psa-horde:/usr/share/psa-horde/pear:.') in /home/httpd/vhosts/xxx.de/httpsdocs/xxx/modules/workshop/inc/workshopform.class.php on line 3

Allerdings kommt diese Fehlermeldung eindeutig vom Server. Hierbei ist mir aufgefallen, das der include_path der php.ini durch die Virtual Host Konfiguration des Webmailers überschrieben wird. Es scheint so, dass dieser Fehler immer dann auftaucht, wenn zeitgleich irgendein anderer Kunde auf diesem Server mit dem Webmailer arbeitet. Das erschreckt mich ein wenig. Der nächste Schritt ist der das meine Vermutung (und es ist nur eine Vermutung daher habe ich keine Beweise) dahin geht, das sich der Server einfach für die Virtual Host Section vom dem einen Kunden mit meiner Anwendung nicht mehr zuständig fühlt, wenn sich jemand in seinem Webmailer befindet.

Die Quickform Klassen sind in einem völlig anderen pear Pfad auf dem Server, und die php.ini enthällt eine include_path Anweisung auf das andere pear Verzeichnis /usr/share/pear. Warum überschreibt Plesk beim Webmailer Horde also die globale Direktive und macht andere Virtaul Hosts unbrauchbar dadurch ?

Ich bin ratlos, gerade weil es eben alles nur Vermutungen sind. Mein Problem scheint aber durch den Webmeiler verursacht zu sein.

liebe Grüße
Ekki

PS: Wenn Du mir allerdings kurzfristig helfen kannst, dann bin ich gerne bereit hierfür zu bezahlen. Das Problem befindet sich auf einem Live Server, mit dem ich ja Geld verdiene, daher steht dem natürlich nichts im Wege, ich will mir ja schließlich keine kostenlosen Leistungen erschleichen, trotzdem sollte man die Ursache heraufinden und die Lösung dann posten, da vielleicht andere Leute auch das Problem haben, oder ich bin der einzige Iditot ;-).
 
Last edited by a moderator:
triumvirat said:
Wenn "Die seite kann nicht angezeigt werden" auftaucht, dann bringt der Reload nix.
Funktionieren alle Website's nicht mehr?
Auch statische HTML-Seiten nicht?
Schon mal zur 'kritischen Zeit' ein "telnet domain.tld 80" gemacht?

Hierbei ist mir aufgefallen, das der include_path der php.ini durch die Virtual Host Konfiguration des Webmailers überschrieben wird.
Ändere (nur mal so zum Testen) den Webmail-VirtualHost in der httpd.include:
Code:
[COLOR="Red"]#[/COLOR]ServerAlias webmail.*
[COLOR="Red"]ServerAlias webmail.meineDomain.tld[/COLOR]
Ich fürchte das der CatchAll evtl. die interne Konfiguration von Apache durcheinander bringt.

Wenn Du mir allerdings kurzfristig helfen kannst, dann bin ich gerne bereit hierfür zu bezahlen.
Falls alle Stricke reissen sollten...

huschi.
 
Hallo Huschi,

leider gibt es keine kritische Zeit, die man benennen könnte. Allerdings hab ich das webmail.* auch schon als Problem angesehen und es auf alle Domains die einen webmailer haben sollen geändert.

Ferner hab ich in der Virtual Host Section vom Webmailer die IP Adresse vom Anwendungsvirtualhost herausgenommen, da ich mehrere IP Adressen auf den Server einsetze. Hat aber leider nix gebracht, er ist trotzdem noch mit der Fehlermeldung :
Code:
Warning: main(HTML/QuickForm.php): failed to open stream: No such file or directory in /home/httpd/vhosts/xxx.de/httpsdocs/xxx/modules/workshop/inc/workshopform.class.php on line 3
gekommen, als ich den Webmailer aufgerufen habe für eine andere Domain innerhalb der anderen Anwendung.

Schlauerweise hab ich aber die Quickform Klassen in das Verzeichnis:
/usr/share/psa-horde/pear kopiert, damit sollte dieser Fehler entgültig weg sein.

Weiterhin habe ich zusätzlich an einer zentralen Stelle eine Zeile ini_set gemacht für session.save_path, weil ich mehrere zeitgleiche Anwendungen habe, die alle in /tmp geschrieben haben, und jetzt jeder ein eigenes Verzeichnis haben um die Session Dateien abzulegen. So hat es mir der Schlund Support geraten, die auch völlig im dunkeln tappen und sich das gesehene nicht erklären können ;-) [**Doch nicht der einzige**]. Mhh... kann mir nicht vorstellen dass es was bringt, aber so kann man es wenigstens ausschließen.

Irgendwie glaube ich eben, dass bei der Anfrage an den Server die Virtual Host Konfigurationen durcheinander kommen. Allerdings stecke ich nicht so tief in der Apache Entwicklung als das ich wüsste, wie der an die richtige V-Host Section kommt und wie man das prüft, ob er auch diese verwendet.
 
So ich habe da etwas gefunden, was vielleicht auch weiter hilft.

die Quickform Klassen erzeugen die Formulare vollständig selbst. So gibt es einen enctype="multiform-data" in Verbindung mit dem action attribut auf z.B. index.php innerhalb des <form Tags. Da hier relativ referenziert wird und der Plesk vielleicht damit Probleme hat, hab ich die komplette URL mit http://... angegeben im action Attribut.

Mal sehen ob das was bringt. Scheint so, als wenn es das Problem aber nur in Verbindung mit dem enctype und relativer Pfadangabe gibt. Heute ist mir das ganze nämlich auch bei phpMyAdmin passiert auf den selben Server. DAbei fiel mir auf, dass auch die diesen enctype verwenden. wenn ich den weglasse, dann habe ich keine Probleme, so wie im Rest der Anwendung, da man in diesem Teil aber ein Bild hochladen kann, brauche ich den enctype.

I'am not amused at all.

Die relative Pfadangabe sollte doch eingentlich vom jeweiligen Browser auch richtig (mit der entsprechenden DOMAIN vorangestellt) angefordert werden. Vielleicht liegt da der Hund begraben.

cu
Ekki
 
Last edited by a moderator:
Back
Top