Reseller und User bekommen leeren Bildschirm nach dem Anmelden

[driessen]

Hallo Forum
ich habe zur Zeit das Problem das ich wenn sich User anmelden um Ihre Domain und Mailuser zu pflegen diesen einen weisen Bildschirm bekommen.

Bei neu angelegten User und Resellern werden die Oberflächen innerhalb von VHCS "normal" angezeigt und alles kann angelegt und gelöscht werden.
Ich weis zur Zeit nicht mehr wo ich noch suchen soll.
Datenbankeinträge verglichen, User setting in den Datenbanken kontrolliert nirgends sehe ich etwas ungewöhnliches.

Rechte Probleme können es nicht sein dann gingen auch die neuen nicht

in der Zeile steht
http://www.domain.tld/vhcs2/reseller/index.php

im Quellcode kommt

<!--
Compression level: 4
Original size: 0 kb
New size: 0.01 kb
Saving: -0.01 kb (0 %)
Time: 0.17 ms
Serverload: 1.04
-->

Ich weiß zur Zeit nicht wo ich noch suchen soll bin fast soweit den Server neu aufzusetzen aber evtl. habt Ihr ja noch eine andere Lösung

Server Debian testing, VHCS 2.8 (was ansonsten wunderbar seinen Dienst tut)

besten dank für Tipps

 

[yavhcsu]

Also, diese Ausgabe von apache2 deuten IMHO auf ein Konfigurationsproblem (php-Direktiven, Rechte) hin. Das jeweilige php-script wird zwar ausgeführt, der generierte html-code jedoch nicht angezeigt.

Daher noch ein paar Fragen:

Verwenden die User als URL die eigene Domäne, also z.B. kundendomain.local/vhcs2 oder die Deines Servers, also z.B. hostingdomain.local/vhcs2, um VHCS aufzurufen?

Besteht der Unterschied (mal Fehler, mal keiner) auch, wenn die gleichen Benutzer via hostingdomain.local/vhcs2 versuchen, auf vhcs zuzugreifen?

Was sagen denn die jeweiligen logs der Kunden (kundendomain.local) in /var/log/apache2/ ?

Hier nach "GET /vhcs2" schauen. Vergleiche die Ergebnisse mit den Domänen, wo es funktioniert.

Schaue auch mal in die /var/log/apache2/access.log rein. Hier werden die Zugriffe auf die Serverdomäne (hostingdomain.local) geloggt.

 

[driessen]

Also, diese Ausgabe von apache2 deuten IMHO auf ein Konfigurationsproblem (php-Direktiven, Rechte) hin. Das jeweilige php-script wird zwar ausgeführt, der generierte html-code jedoch nicht angezeigt.

Daher noch ein paar Fragen:

Verwenden die User als URL die eigene Domäne, also z.B. kundendomain.local/vhcs2 oder die Deines Servers, also z.B. hostingdomain.local/vhcs2, um VHCS aufzurufen?

sowohl als auch es ist egal ob ich über das Admin in die jeweilige Domain wechsle oder ob ich mich direkt über die Domain oder über die Hauptdomain versuche anzumelden bleibt sich gleich.

Ich habe testweise einen neuen Reseller angelegt und dazu noch eine Domain in beides kann ich über aus dem Adminbereich hineinwechseln
und auch sauber über die Anmeldemaske die unterhalb des HTML liegt damit anmelden.
bei den anderen Domains wurde das vhcs.hmtl umbenannt in tools.html
aber wie gesagt das spielt keine Rolle ich kann auch das html einer ganz anderen Domain nehmen mit den vorher angelegten Domain weißer Bildschirm mit den Neuen alles ok

Was sagen denn die jeweiligen logs der Kunden (kundendomain.local) in /var/log/apache2/ ?
Hier nach "GET /vhcs2" schauen. Vergleiche die Ergebnisse mit den Domänen, wo es funktioniert.

ich sehe keinen Unterschied in den Logfiles, es werden die gleichen Files per Get angefordert
alle aus dem Verzeichniss /vhcs2/themes/modern_blue/

Schaue auch mal in die /var/log/apache2/access.log rein. Hier werden die Zugriffe auf die Serverdomäne (hostingdomain.local) geloggt.

auch im Access.log keine Auffälligkeiten oder andere Meldungen deswegen bin ich ja schon am verzeifeln ich habe das ganze in der letzten Stunde nochmal nachgestellt und geprüft

 

[CentY]

hast du auch ins error.log geschaut ? vorallem auf dem error.log von vhcs-domain.tld-error.log

 

[driessen]

auf die Idee war ich noch gekommen im Error log nachzuschauen
ist aber leider auch nicht ergiebigfür mich evtl könnt Ihr was mit anfangen.
es sind allerdings die gleichen Meldungen wie sie auch bei den Domains wo alles ok ist sind

[Tue Nov 06 21:30:17 2007] [error] [client 193.158.37.230] PHP Notice: Undefined index: data in /var/www/vhcs2/gui/include/spGzip.php on line 134, referer: http://fblan.de/vhcs2/admin/manage_users.php
[Tue Nov 06 21:30:17 2007] [error] [client 193.158.37.230] PHP Notice: Undefined index: data in /var/www/vhcs2/gui/include/spGzip.php on line 134, referer: http://fblan.de/vhcs2/admin/manage_users.php
[Tue Nov 06 21:30:17 2007] [error] [client 193.158.37.230] File does not exist: /var/www/virtual/fblan.de/htdocs/favicon.ico

was ich nicht verstehe ist warum es dann nicht bei den neuen Domains auftritt, die aufgerufenen Dateien sind doch die gleichen. ich finde es einfach nicht.

ich tippe dabei irgendwie eher auf eine Fehler in den Datenbanktabellen bzw. in den Einträgen aber auch da habe ich schon verglichen und nichts auffälliges gefunden.

 

[CentY]

Hm ... das is wieder son Grund warum ich PHP nicht leiden kann da es nie brauchbare Fehlermeldungen liefert wenn was schiefläuft. Aber ich schau mal nach was da steht und was los sein könnte.

 

[yavhcsu]

Also, wenn man über die Hauptdomäne als admin ins vhcs geht,

anschließend über change in den Benutzer "NEU.local" wechselt, gelangt man in problemlos die Übersicht,

man wechselt wieder zurück zum admin über den kleinen roten Knopf und gelangt in die Übersicht des admin,

wechselt man über change in den Benutzer "ALT.local", erhält man anstelle der Übersicht ein weisses Bild, wo im Quellcode die Angaben über Compression, etc. stehen.

Sehe ich das soweit richtig? Es spielt auch keine Rolle, in welcher Reihenfolge Benutzer "ALT.local" und "NEU.local" nach dem Einloggen als admin aufgerufen werden.

Die Angaben im Quellcode kommen übrigens vom Code, der auch diese PHP Notice in den logs verursacht.

Wie ist das mit der Sprache, ist diese bei ALT.local und NEU.local gleich eingerichtet? Was ist mit Traffice Usage und Disk Usage. Worauf ich hinaus will, ist dass evt. variable Daten zu einem Fehler in VHCS führen und dieses sein Arbeit nicht fertigstellt, sondern mit einem Fehler aus dem jeweiligen Code aussteigt. Das was man dann sieht bzw. nicht sieht, ist evt. das zuletzt korrekt ermittelte. Da die Seiten ja nur generisch sind, ist also nur das relevant, was auf der Übersicht für den jeweiligen Benutzer angezeigt wird. So wird z.B. die Grafik für den Auslastungbalken für Traffic Usage berechnet. Ein nicht erwarteter Wert könnte hier einen Fehler verursachen und letzten Endes den exit aus der übergeordneten Funktion herbeiführen.

 

[driessen]

Also, wenn man über die Hauptdomäne als admin ins vhcs geht,
anschließend über change in den Benutzer "NEU.local" wechselt, gelangt man in problemlos die Übersicht,

ja so ist es

man wechselt wieder zurück zum admin über den kleinen roten Knopf und gelangt in die Übersicht des admin,

auch richtig

wechselt man über change in den Benutzer "ALT.local", erhält man anstelle der Übersicht ein weisses Bild, wo im Quellcode die Angaben über Compression, etc. stehen.

wieder richtig

Sehe ich das soweit richtig? Es spielt auch keine Rolle, in welcher Reihenfolge Benutzer "ALT.local" und "NEU.local" nach dem Einloggen als admin aufgerufen werden.

4 Fragen richtig beantwortet *gg es ist auch egal ob du dich nur als Benutzer neu oder als Benutzer alt direkt anmeldest

Die Angaben im Quellcode kommen übrigens vom Code, der auch diese PHP Notice in den logs verursacht.

Wie ist das mit der Sprache, ist diese bei ALT.local und NEU.local gleich eingerichtet? Was ist mit Traffice Usage und Disk Usage. Worauf ich hinaus will, ist dass evt. variable Daten zu einem Fehler in VHCS führen und dieses sein Arbeit nicht fertigstellt, sondern mit einem Fehler aus dem jeweiligen Code aussteigt. Das was man dann sieht bzw. nicht sieht, ist evt. das zuletzt korrekt ermittelte. Da die Seiten ja nur generisch sind, ist also nur das relevant, was auf der Übersicht für den jeweiligen Benutzer angezeigt wird. So wird z.B. die Grafik für den Auslastungbalken für Traffic Usage berechnet. Ein nicht erwarteter Wert könnte hier einen Fehler verursachen und letzten Endes den exit aus der übergeordneten Funktion herbeiführen.

Die Sprache ist auch bei allen gleich auf lang_German und layout auf blue, steht auf jeden Fall so in der Datenbanktabelle user_gui_props .
Der Server ist mehr am ideln wie am arbeiten (Dual 1400 Tulatin, Raid 5 mit 6 SCSI Platten, 3 GB Ram) und den ganzen Tag säuft der Kaffee ohne ende und quatscht mit sich selbst.
Die Seiten selber sind eigentlich klein die größte hat mal gerade 300 MB(das meiste Bilder).
Aber man könnte ja mal die Werte neu berechnen lassen wenn das hilft.
domain_disk_usage domain_disk_limit
455855967 0
63357 20
88610251 100
61753 1000
44092223 500
23119278 500
21850624 200
122089 50
359523651 500
9563236 50
148406302 500
52012139 500
56223134 500
35170864 500
61712 0
59868 0 das letzte ist die Testdomain

 

[yavhcsu]

Variablen dumpen

Je mehr ich in den code schaue, desto eher denke ich, dass es ein bestimmter variabler Wert je Benutzer ist, der warum auch immer ein Problem macht.

Man kann in der /srv/www/vhcs2/gui/include/vhcs-lib.php ungefähr in Zeile 112 folgende Wert aktivieren (die beiden "//" entfernen)

//$cfg['DUMP_GUI_DEBUG'] = '_on_';

Damit werden sämtliche benutzte Variablen unter der genrierten Seite angezeigt. Vieleicht ergibt sich beim Betrachten der Inhalte ein Anhaltspunkt, sofern dieser bei NEU.local überhaupt erzeugt wird.

Doch Vorsicht mit eventuellem Posten, hier sind auch kritische Variablen drin, die Paswörter und ander Infos beinhalten.

Wie ist es, wenn die Werte für max. Traffic und Space Limit auf Null gesetzte werden?
Gibt es evt. offene Support Tickets?

 

[driessen]

Ich habe es gefunden

Ich habe jetzt einfach die ganze Datenbank gesichert und dann die Domain_trafik geleert.

Alle Domains rennen wieder.

Ich werde mir die Tabelle mit den Trafik werten nochmal anschauen warum die Einträge darin Probs gemacht haben.

Besten Dank an alle

 

[yavhcsu]

Nun, ich tippe auf ein Problem bei der Generierung der Grafik anhand der Werte in der domain_traffic, hier speziell der Laufbalken, wenn z.B. die maximalen Werte für Traffic bzw. Space überschritten werden.

Je nachdem wie der Code organisiert ist, lässt sich so etwas schlecht testen.

Aber warten wir es doch einfach ab, ich denke nach einer Weile wird das Problem wieder auftauchen, wenn die Werte für den traffic wieder einen bestimmten Wert erreicht haben.