[gelöst] Admin Login erzeugt 500 Servererror

Bei dem von Dir geschilderten WSOD (White Screen of Death) solltest Du die Serverlogfiles konsultieren. Hier sollte ein Hinweis stehen was den Fehler auslöst.

"There was a problem with your form submission. Please wait 11 seconds and try again." Das hat meiner Ansicht nach nichts mit Deinem Problem zu tun, sondern ist vermutlich eine Meldung vom Honeypot-Spamschutz-Modul.

sondern daran, dass die Adminumgebung nunmal mehr Module laden muss.
Vermutlich liegt es an einem zu knappen Speicher, oder an zu geringer Prozesszeit.

Genaues erfährt man erst, wenn man in die error.log schaut.

Wo die ist, ist vom Provider abhängig. Bei einigen Providern muss sie vom Support angefordert werden.

... vielen Dank für eure Hinweise!

Habe gerade nachgesehen und festgestellt, dass ich nur Access-Logs einsehen kann, weil Error-Logs nicht aktiviert waren. Das habe ich aber jetzt gemacht, werde heute abend weitere Einloggversuche unternehmen (muss jetzt leider weg) und dann im neuen Error-log nachsehen, was dort steht. Vielleicht werde ich schon selbst daraus schlau.

Nochmals DANKE! Wieder was gelernt.

Ciao, Thomas

... dies:
[Sat Aug 15 18:21:55 2015] [error] [client 86.218.193.64] File does not exist: /home/www/web296/html/favicon.ico
[Sat Aug 15 18:22:33 2015] [error] [client 86.218.193.64] File does not exist: /home/www/web296/html/favicon.ico
[Sat Aug 15 18:22:33 2015] [error] [client 86.218.193.64] File does not exist: /home/www/web296/html/favicon.ico
[Sat Aug 15 18:41:56 2015] [error] [client 77.0.140.163] File does not exist: /home/www/web296/html/favicon.ico, referer: http://www.kirchenmusikliste.de/
[Sat Aug 15 18:43:10 2015] [error] [client 77.0.140.163] File does not exist: /home/www/web296/html/favicon.ico, referer: http://www.kirchenmusikliste.de/startseite-0?destination=node/6148

Okay, ich habe jetzt das fehlende Favicon hochgeladen; aber das kann noch nichts mit dem beschriebenen Fehler zu tun haben, oder?

Bin ziemlich ratlos.

kommt der Fehler noch?
Steht im error log jetzt etwas anderes?
steht etwas im drupal protokoll?

So ist das ein bisschen ein Stochern im Nebel.

Was ist passiert, seit es das letzte Mal funktioniert hat?

Leider bleibt der Fehler:
An meine Admin-Adresse lasse ich mir den Link zum Zurücksetzen des Passwortes schicken. Der Link funzt.

Auf dieser Seite drücke ich dann den Button ANMELDEN, damit ich auf die Seite komme, wo ich das Passwort neu setzen kann.
Der URL lautet: http://www.kirchenmusikliste.de/user/1/edit?pass-reset-token=m8JE3yM75E_...

Diese Seite ist aber weiß. Der Sourcecode ist nicht etwa , sondern nur: 1

Versuche ich im Handybrowser (Blackberry) die Seite www.kirchenmusikliste.de aufzurufen, kommt sofort "Fehler 500. Technische Probleme am Server."

Das error_log zeigt jetzt keine Fehler mehr wegen des Favicons an, aber dies ist neu:
[Sat Aug 15 20:43:03 2015] [error] [client 180.76.15.159] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.

Mein letzter Login als Admin war vor ca. 3 Wochen (dazwischen war ich im Urlaub). Da hat alles noch geklappt.

Allerdings hat mein Anbieter am 12.8. diese Meldung an seine Kunden gesendet:
=====================
Der Webserver can05.de wurde aufgrund einer Hardwarestörung vorzeitig umgezogen.
Beachten Sie:
Da auch wir mit der Zeit gehen müssen, werden alle Server auf 64 Bit-Systeme umgestellt, dies bedeutet, dass es PHP5.2.17 nicht mehr gegeben wird, weitere Änderungen durch die 64 Bit-Systeme werden Sie nicht beeinträchtigen.
PHP5.2.17 ist daher für den Webserver abgeschaltet.
PHP5.6 ist ab sofort für den Webserver nutzbar.
Sollten Sie eigene Domains per DNS nutzen, so ändern Sie die IP-Adresse wie folgt:

213.131.245.133 in 217.172.166.169
213.131.245.158 in 217.172.166.169

Der alte Webserver wird innerhalb 72h abgeschaltet.

Sollten Sie einen Fehler erhalten (Wordpress) MemoryLimit dann gehen Sie in IP-CONF unter httpd.Spezial und stellen das MemoryLimit auf den höchsten vorhandenen Wert, sollte der Bereich nicht vorhanden sein, so wenden Sie sich bitte an den Support.
=========================

Und am 4.8. kam dies:
========================
Das Ende für SSLv3 ist da!

Sehr geehrter Herr Thomas Schmidt,

Wir haben uns lange gewerht, doch auch wir müssen mit der Zeit gehen, und Sicherheitsbelange berücksichtigen.

Dies betrifft aktuell nur alle umgezogenen Webserver mit 64Bit Systemen.

Aufgrund der aufgetauchten Sicherheitslücke namens Poodle wurde das bisher zusätzlich unterstützte SSLv3 Protokoll abgeschalten. Wir suchten seit Bekanntwerden der Sicherheitslücke nach weiteren Alternativen um auch noch sehr alten Browsern und Programmen eine sichere Verbindung zu ermöglichen.
Leider gibt es keine, und um dieser Sicherheitslücke keinen Angriffspunkt zu bieten, schalten wir ab sofort die SSLv3 Version ab, dies im Web, sowie E-Mail-Verkehr, zwingen dadurch aufrufenden Browser oder das Programm eine sichere TLS Verbindung aufzubauen wenn verschlüsselt übertragen wird. Das TLS Protokoll gehört seit mehr als 15 Jahren bereits zum Standard und wird von allen gängigen Browser seither unterstützt.
Sollten Sie mit Ihrem E-Mail-Client Probleme, beim Versand oder Empfang via SSL haben, stellen Sie auf TLS um, wenn dies nicht läuft, ist die eingesetzte Software veraltet und sollte auf den neusten Stand gebracht werden.

Mehr Infos unter: heise.de
=================

Da die Seite aber funktioniert und auch das Login als normaler User möglich ist, glaube ich nicht, dass es am Server liegt. Lediglich das Admin-Login macht Probleme.

Ronald, danke für Dein Mitdenken und Überlegen!

Ciao, Thomas

php 5.6 könnte natürlich ein Problem sein: Schau mal hier https://www.drupal.org/node/2363219

Bietet Dein Hoster vielleicht auch noch andere php-Versionen an? Dann probiere doch mal eine frühere Version.

noch auf die alte Adresse zeigt, und jeder Zugriff einen Redirect veranlasst, was irgendwann zu dieser Meldung "too many redirects" führen muss.

Es ist also kein Problem im Drupal, sondern eines in der Serverkonfiguration, bzw. DNS-Zuweisung.

Wenn du die Domain auf die neue IP-Adresse gelegt hast, sollte spätestens in 48 Stunden der Zauber vorbei sein.

... dem Support des Hosters geschrieben. Bin gespannt auf die Antwort und werde dann hier berichten. Danke für Deine Analyse! Ich hätte den Eintrag im error_log nicht verstanden.

Ciao, Thomas

Danke für Deine Idee! Aber das Login als normaler User klappt ja. Es können sich auch Besucher als neue User registrieren. Darum kann das eigentlich nicht die Ursache sein. Ich kann mich nur nicht als Admin anmelden.

Dem Support habe ich jetzt mal die Meldung des error_logs gesendet. Ronalds Idee mit der falschen DNS-Zuweisung könnte die Lösung sein.

Ciao, Thomas

... dass serverseitig alles OK sei:

"Die Domain zeigt auf den can05.de im DNS ist alles ok."

Meine Idee: Meinen normalen Userzugang (Nicht-Admin) zum Admin "upzugraden" - allerdings nicht über das Admin-Menü im Drupal, denn das erreiche ich ja nicht, sondern in der Tabelle der Drupal-Datenbank auf dem Server. Leider sehe ich da in der Tabelle "users" kein Feld für ADMIN. Oder ist der Gedanke ganz abwegig?

Ciao, Thomas

Du kannst versuchen, die User-ID zu tauschen. Der User1 (mit der ID 1) wird ja "nur" über den ID-Eintrag in der Tabelle Users gefunden. In dieser Tabelle kannst Du auch nachsehen, ob es auch einen User 0 (den Gast) gibt. Der ist mir mal bei einem Umzug abhanden gekommen und das machte erhebliche Probleme.

Wenn meine Anmeldung als Admin mir nur eine weiße Seite anzeigt, so bin ich seltsamerweise denncon eingeloggt, denn unter "wer ist online?" wird mein Admin-Username angezeigt. Das kann ich allerdings nur sehen, wenn ich mir als normaler User einwähle.

Das error_log schreibt weiter mit:

[Sun Aug 16 07:43:25 2015] [error] [client 188.212.21.105] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace., referer: http://www.archiv.kirchenmusikliste.de/bilder/details.php?image_id=94&se...
[Sun Aug 16 13:40:42 2015] [error] [client 23.229.8.247] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace., referer: http://www.archiv.kirchenmusikliste.de/bilder/details.php?image_id=94&se...

Dankbar für jede Idee zur Lösung dieser Sache ist weiterhin
Thomas

Hast Du irgendwelche Weiterleitungen aktiv (über Redirect, Globalredirekt oder über Regeln)? Dann würde ich die zugehörigen Module mal über die Datenbank ausschalten (in der Tabelle "system" den Status auf 0 setzen) und anschließend alle Tabellen, die mit cache_ anfangen und auch chache selbst leeren nicht löschen.

dass noch Reste der alten IP-Adresse im cache herumfahren, oder in Links hinterlegt sind.

Eine DNS-Change kann bis zu 48 Stunden brauchen, bis er weltweit durchrepliziert ist.

Ein Userwechsel bringt nichts, weil es nicht um den User, sondern um die Links innerhalb des Systems geht.

Cache löschen, ggf. redirects neu aufbauen lassen, und warten, ist wahrscheinlich der richtige Weg.

Module, die bei mir aktiv sind, sind diese:

adaptivetheme
admin_menu
admin_menu_toolbar
adsense
adsense_click
adsense_cse
adsense_managed
adsense_oldcode
adsense_search
advanced_help
block
brilliant_gallery
calendar
church_music_list
ckeditor
color
comment
contact
contextual
ctools
dashboard
date
date_all_day
date_api
date_popup
date_repeat
date_repeat_field
date_tools
date_views
dblog
ds
ds_format
ds_forms
ds_search
ds_ui
exclude_node_title
features
field
field_sql_storage
field_ui
file
file_entity
filter
forum
gmap
gmap_location
googleanalytics
help_example
honeypot
image
libraries
link
list
locale
location
location_cck
location_node
location_user
locationmap
media
menu
node
number
options
page_manager
panels
panels_ipe
panels_mini
panels_node
path
pathauto
pathologic
php
piwik
pixture_reloaded
pubdlcnt
rdf
reg_with_pic
revenue_sharing_basic
search
search_config
simplified_social_share
superfish
syslog
system
tabtamer
taxonomy
text
token
tracker
transliteration
trigger
update
user
user_restrictions
user_restrictions_ui
views
views_content
views_php
views_ui

Die sind in der Tabelle "system" auf 1 gesetzt. Ein Redirct oder ähnliches finde ich da nicht.

Aber vielleicht klappt ja dein Tipp, die cache_-Tabellen zu leeren. Bevor ich da etwas zerschieße, nur sichherheitshalber eine Rückfrage: Ich lösche nicht die Tabellen, sondern lösche nur alle Einträge, die in ihnen enthalten sind? Ist das richtig?

Danke für Deine Mithilfe, Werner!

Ciao, Thomas

Bei Deinen Modulen sehe ich auch kein redirekt. Für die Caches gilt leeren, d.h. die Einträge werden gelöscht, aber die Struktur der Tabelle bleibt erhalten.

Alle cache_-Tabellen mit dem Befehl "leeren(Truncate)" geleert. Jetzt warten wir mal die nächsten Tage ab.
Danke für Deine Erklärungen! Habe wieder was dazu gelernt.

Ciao, Thomas

Bisher hat sich nichts geändert.

In einem früheren Posting schrieb Werner:
"Du kannst versuchen, die User-ID zu tauschen. Der User1 (mit der ID 1) wird ja "nur" über den ID-Eintrag in der Tabelle Users gefunden. In dieser Tabelle kannst Du auch nachsehen, ob es auch einen User 0 (den Gast) gibt. Der ist mir mal bei einem Umzug abhanden gekommen und das machte erhebliche Probleme."

Das habe ich mal probiert. Es geht. Mein Admin-Zugang hat jetzt die Nummer 131, mein normaler User-Zugang hat jetzt die 1 (=bisher die Admin-User-ID). Die Folge: Mit meinem Adminnamen kann ich mich mit User-ID 131 jetzt einloggen, komme aber nicht ans Admin-Menü. Und als User 1 habe ich wieder die weiße Seite, wenn ich mich einloggen will.

Einen User 0 gibt es tatsächlich nicht. Allerdings sehe ich in der Tabelle "users" eine User-ID 2 mit dem Namen "Besucher" und dann ohne weitere Einträge wie Passwort etc.

Die error_log schreitb weiter mit:
[Thu Aug 20 09:09:22 2015] [error] [client 66.249.64.112] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.
[Thu Aug 20 10:30:25 2015] [error] [client 66.249.64.117] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.
[Thu Aug 20 15:24:38 2015] [error] [client 66.249.64.117] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.

Wie kann ich dem funktionierenden User-Zugang mit der ID 131 in der Tabelle den Adminstatus zuweisen? Ich sehe da kein Feld, wo das vermerkt ist.

Oder hat noch jemand eine Idee, was ich unternehmen könnte?

Danke im Voraus für jeden Tip!

Ciao, Thomas

Dann gib bitte dem Besucher die User-ID 0!!! Danach die Caches leeren und noch mal probieren. Die Caches notefalls zu Fuß, d.h. über die Datenbank leeren (alle Tabellen, die mit cache_ anfangen und auch cache selbst leeren aber nicht löschen).

wenn du die ID änderst, ist ein Zeichen, dass es tatsächlich, wie vermutet, an den Adminfunktionen liegt.

Offenbar stört ihn irgendein redirect, der vielleicht recursiv, also in einer Endlosschleife, läuft.

Schau mal in der settings, ob dort irgendwo der absolute Pfad zum alten Server mit IP-Adresse steht.
Oder es gibt ein Dokument, das nur vom Admin angesehen werden kann, in dem ein Link mit IP-Adresse steht.
Möglicherweise eine Bildergalerie, oder Ähnliches?

Da es die geänderte IP offenbar nicht war, solltest Du vielleicht die anderen Änderungen bei Deinem Provider in Erwägung ziehen (aka Wechsel der php-Version). Wie schon mal angeregt, probier doch mal eine andere php-Version aus sofern Dein Hoster das unterstützt.

Was die Fehlermeldungen aus dem error-Log angeht die Du postet, habe ich den Verdacht, dass diese vielleicht überhaupt nicht in Zusammenhang mit dem Problem stehen. Ist da denn ein zeitlicher Zusammenhang gegeben zwischen Deinen Anmeldeversuchen und den Fehlermeldungen?

- Hier ist der Refererer ja archiv.kirchenmusikliste..., also vermutlich gar nicht deine eigentliche Drupal-Installation

Du wolltest doch auch bei Deinem Provider nachfragen? Was hat die Nachfrage ergeben?

Das werde ich mal erfragen.

Ich sehe keinen zeitlichen Zusammenhang, denn die Meldungen bezogen sich auf Zeiten, an denen ich es gar nicht versucht hatte. Das ist also wahrscheinlich ein ganz anderes Problem.

- Hier ist der Refererer ja archiv.kirchenmusikliste..., also vermutlich gar nicht deine eigentliche Drupal-Installation[/quote]
Die Drupal-Installaton liegt im Verzeichnis /html/dr/, die Domain lasse ich direkt darauf verweisen. In einem anderen Ordner /hml/archiv/ liegt die bisherige Homepage. Die subdomain www.archiv.kirchenmusikliste.de verweist darauf. Dem referer werde ich aber nachgehen und das fixen.

Der Support schrieb, dass serverseitig alles OK sei: "Die Domain zeigt auf den can05.de im DNS ist alles ok."

Ich werde jetzt mal den verschiedenen Hinweisen auf meine Frage nachgehen und dann scheiben, was passiert.
DANKE!
Ciao, Thomas

Erledigt. Das brachte leider keine Lösung. Wenn ich mich mit der User-ID 1 (jetzt wieder meinem Admin-Usernamen zugelrdnet) einloggen will kommt eine leere Seite.

Das werde ich morgen mal suchen.
Meinst Du eine bestimmte settings-Datei? In der sites/default/settings.php steht jedenfalls nichtts dergleichen.
Danke für die Hinweise. Ich werde dem nachgehen.

Ciao, Thomas

auf die alte IP-Adresse hin durchsucht, denn der Support schrieb ja nach einer Serverumstellung dies:

===============
Sollten Sie eigene Domains per DNS nutzen, so ändern Sie die IP-Adresse wie folgt:

213.131.245.133 in 217.172.166.169
213.131.245.158 in 217.172.166.169
===============

Aber es gibt bei mir keine Datei, die irgendwo den String 213.131.245. enthält.

Und Angaben in der error_log wie diese:

=======================

[Mon Aug 24 13:52:22 2015] [error] [client 91.200.12.138] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace., referer: http://www.archiv.kirchenmusikliste.de/xmlrpc.php

[Mon Aug 24 13:52:22 2015] [error] [client 91.200.12.138] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace., referer: http://www.archiv.kirchenmusikliste.de/bilder/xmlrpc.php

=======================

weisen auf eine Datei xmlrpc.php hin, die es gar nicht gibt, und zwar in keinem der beiden genannten Ordner.

Habe gerade den Support angeschrieben mit der Bitte, das MemoryLimit auf den höchsten Wert zu setzen. Mal sehen, ob es etwas bringt.

ob das relevant ist, muss sich noch herausstellen.

Alle Fehlermeldungen beziehen sich auf die Subdomain "archive"

Kann es sein, dass hier in der DNS-Konfiguration noch die falsche IP hinterlegt ist?

Der referer "archive" als Fehlerquelle fiel mir auch auf. Der Support schrieb gerade dies:
============
Die Auflösung ist richtig, daher im DNS ist alles OK.
============

In der error_log finden sich auch solche referer:
[Mon Aug 24 16:32:54 2015] [error] [client 80.150.2.82] Request ... referer: http://...support.de/otrs/index.pl?Action=AgentTicketZoom;TicketID=122638

Das war der Support selbst.

Und auch dies:
referer: http://www.drupalcenter.de/node/53724
also ein Link aus diesem Forum

Das sind also recht harmlose Verweise, durch die man der Sache nicht auf die Schliche kommen kann.

Was ich aber gemacht habe (und jetzt klappt es wieder):
1. Browsercache des Firefox leeren
2. Rechner neu booten

Was mich in den letzten Tagen immer gewundert hat, war:
Wenn ich mich als Admin auf meiner Seite anmelden wollte, ging das gar nicht, egal in welchem Browser.

Wollte ich mich aber als authentifizierter User anmelden, ging das nur, wenn ich vorher den Cache des Browsers geleert hatte. Das ging nur bei Chorme und bei IE. Das Leeren des Caches im Firefox half überhaupt nicht. Egal, ob ich mich als Admin oder User anmelden wollte: Auch nach dem Leeren des Caches von Firefox bekam ich schon beim Aufrufen der Site nur eine weiße Fläche angezeigt.

Nun habe ich wieder den Firefox-Cache geleert und den Rechner neu gebootet (Win 7).

Beim Aufruf der Site im Firefox bekam ich plötzlich das Admin-Menü angezeigt, ohne dass ich mich eingeloggt hatte. Dazu kam die Meldung "Another user Pfeife is already logged in... Yout tried to use a one-time link as user ..."
Siehe Anlage 1

Habe daraufhin im Adminmenü mir den Statusbericht angesehen und ein bisschen herumgeklickt, um zu prüfen, ob ich nicht wieder rausegworfen werde. Und siehe da: Alles läuft wie geschmiert.

Habe mich abgemeldet und als Admin wieder angemeldet. Auch als User. Klappt.

Jetzt geht es auf einmal wieder.

Selbstheilungskräfte? Wer weiß?

Dass es am Cache des Firefox gelegen hat, kann ich mir eigentlich nicht vorstellen.

Darum kann ich zwar das Problem als "gelöst" kennzeichnen, kenne die Ursache für die Lösung allerdings nicht.

Ich gehe jetzt mal Berichte/Recentlog Messages durch. Da steht so allerhand ...

Siehe Anlage 2

Allen, die sich für mich den Kopf zerbrochen haben und versucht haben, mir mit ihren Ansätzen zu helfen, sage ich:

Dankemercithankyoueucharistoubedanktgrazieschukranmultumesctak!

Ciao, Thomas

Der Support schrieb mir ja:
================
Die Auflösung ist richtig, daher im DNS ist alles OK.
Prüfen Sie ggf. im Webmanager unter httpd.Spezial die Einstellungen uns setzen diese neu, ggf. hilft dies weiter.
================

Ich habe dort die Liks auf die Subdomain www.archiv.kirchenmusikliste.de einfach noch einmal neu definiert. Das war natürlich keine Änderung zum bisheirgen Zustand. Aber wer weiß ....
Außerdem habe ich das MemoryLimit auf den höchsten Wert (130 MB) gesetzt.
Ich sehe da keinen Zusammenhang zu meinem Problem; aber das waren die Dinge, die ich unternommen hatte, bevor es wieder funktionierte.

Ciao, Thomas

Der Support eines Providers gibt nicht gerne zu etwas vergessen zu haben.
Dann wird es schnell gemacht - und war so.
Da die DNS-Replikation bis zu 48 Stunden dauern kann, aber nicht muss, passt das.