Nach Update auf 6.3.9 Error 500

[e_herrmann]

Zuerst versuchte ich direkt auf 6.4.4, dabei blieb der Installer bei DB aktualisieren stehen.
Danach versuchte ich den Zwischenschritt auf 6.3.9. Hier lief der Installer durch.
Das Frontend läuft, allerdings kann ich mich nicht mehr einloggen. Nach dem Abschicken des Anmeldeform kommt Fehler 500.
Auf das Serverlog habe ich leider keinen Zugriff.
Ich habe schon die Dateien aus diesem Bug ausgetauscht, aber das brachte nichts.
http://qa.webedition.org/tracker/view.php?id=8308
Es ist ein größeres Hostingpaket bei 1&1 mit derzeit PHP 5.4.
Weiß jemand Rat, wie man hier weiterkommt?

Danke und Grüße
Elko

[mokraemer]

bei 1&1 hast du doch zugriff auf die Log-Dateien.

Ich vermute mal, daß hier das php kein mysql mehr hat, wenn er bei der DB stehen bleibt.

Aber ohne logs, kann man das nicht wirklich debuggen. bei der login sache könntest du selbst in den tblErrorlog schauen, ob er da was geloggt hat (setzt voraus das Logging eingeschaltet ist)

[e_herrmann]

Hi Marc,
ich habe bei dem Projekt nur den FTP-Zugang, deshalb kein Server Backend.

Habe jetzt aber festgestellt, dass die Seite doch nicht bei 1&1 liegt, sondern bei T-online. Das macht das ganze nicht leichter.
Dort gibt es im Webspace ein cgi_error_log, das fängt aber den Fehler 500 aber nicht.
Auch im Errorlog von WE wird der nicht geloggt.
Wie gesagt, die Website läuft noch, nur der Login im Backend bring den Fehler 500.

Hast du noch einen Tipp, was man machen kann?

[e_herrmann]

Kann es sein, dass hier die Server-Power nicht ausreicht? Der Fehler 500 kommt nach exakt 10s, das finde ich eigentlich recht früh, oder?
Hat die 6.3.9 eine andere PW-Verschlüsselung, die hier entsprechend Power braucht?

[mokraemer]

t-online.... da hatten wir schon mal irgendwie Probleme....
10s nee, das sollte ansich für alles relevante ausreichend sein. Sicherlich braucht das Passwort performance - aber keine 10s - das liegt eher in der Ordnung von 1-1.5s.
10s klingen eher nach RAM, oder er hängt sich irgendwo dazwischen auf, bzw. wird nach der maximalen Ausführungszeit von 10s gekillt (weshalb es vermutlich kein Log gibt). Nur wo er die Zeit verbraucht kann ich schwer erraten - wie du aus anderen Projekten sicherlich weist ist das kein normales Standardverhalten.

[e_herrmann]

Hi Marc,
könntest du mal in die phpinfo() schauen, ob du da was siehst. Dort läuft bsw. auch Suhosin, da ist ja auch immer schwer zu sagen, was da stört.
Die Funktionen sind dort wohl auch recht kastriert, siehe Info hier (allerdings kann man wohl mit eigenen php.ini Dateien arbeiten:

"chmod" nicht nötig
CHMOD steht für Change Mode und wird in UNIX-basierten Betriebssystemen verwendet, um die Zugriffsrechte für Dateien bzw. Verzeichnisse festzulegen. Für die Datei bzw. das Verzeichnis können dabei verschiedene Rechte vergeben werden, z. B. für lesenden, schreibenden oder ausführenden Zugriff des Besitzers einer Datei, seiner Gruppe oder aller Benutzer. Der Befehl CHMOD ist bei unseren Homepages nicht notwendig und daher serverseitig deaktiviert. Auf unseren Webservern wurde ein anderes Sicherheitskonzept eingesetzt, der Dateizugriff funktioniert im Hosting der Deutschen Telekom auch ohne Änderung der Datei- oder Verzeichnisrechte.

.htaccess nicht möglich
Aus Sicherheitsgründen ist die Verwendung von .htaccess-Dateien zur Serverkonfiguration nicht möglich. Alle Einstellungen, die über die .htaccess-Datei an der PHP-Installation vorgenommen werden sollen, können Sie über Ihre eigene php.ini-Datei vornehmen (s. o.). Einen Passwortschutz für ein Verzeichnis legen Sie bitte im HomepageCenter an.

[mokraemer]

.htaccess nicht möglich

das ist allerdings eine massive Einschränkung. Daraus resultiert eigentlich fast direkt, daß ein sicherer Betrieb auf der Plattform nur mit manueller Nacharbeit möglich ist, in dem alle .htaccess Datei-Einstellungen in die php.ini übertragen werden!

Also auf Anhieb sehe ich in der Info nix was mir auffällt. Ich hab mir hier aber auch nie ein "Suchmuster" gemerkt, denn die Server schreiben aus dem Grund ja Logs in denen Sie genau reinschreiben, was ihr Problem ist. Selbst bei den Fehlern da muß man ab und zu noch "raten" was er will. Jeder Hoster hat Fehlerlogs, die im schlechtesten Fall nur über den Support zugänglich sind. Sind sie gar nicht zugänglich sollte man den Hoster dringend wechseln - das ist ein absolutes No-Go. Ohne diese Logs ist ein Fehlverhalten schlicht gar nicht einzugrenzen. Gerade die 500er Fehler sind die wichtigen, denn die lassen sich oft nicht mal vom Errorhandler in php fangen (leider) und müssen extern geloggt werden. Was ihn hier stört ist reine Spekulation.

Btw. wenn der Updater beim DB Update stehen blieb, müßtest du dazu eigentlich Einträge im Updatelog/Fehlerlog gehabt haben. Auch das ist eher verwunderlich weil selbst wenn es zu Problemen beim DB Update gekommen wäre, er nicht hängen bliebe.