Login Problem ISPconfig

[KurtSt]

Hallo
Ich verwende Ubuntu 14.04.1 mit MySQL 5.5.53. Der ISPconfig-Server läuft seit langem. Seit dem Update auf ISPconfig 3.1.1p1 funktioniert das Login in ISPconfig nicht mehr. Es ist der bekannte Fehler: Das Login ist an sich erfolgreich (im Log), man bleibt aber auf der Login-Seite hängen.
Ich fand einige Diskussionen zum Thema, die meisten recht alt. Was sind die aktuellen Erkenntnisse zur Lösung dieses Problems?
Besten Dank

 

[Till]

Browser cache und cookies löschen.

 

[KurtSt]

Das habe ich gemacht, ich habe von anderen Browsern und anderen Maschinen probiert. Immer dasselbe Verhalten. Falsche Passwörter werden sauber abgefangen und angezeigt. Nur beim korrekten geht es nicht weiter.

 

[madjoe1974]

Ich habe genau das selbe Problem und bin auf folgendes gestoßen:

wenn ich ispconfig per FQDN aufrufe kann ich mich nicht einloggen bzw es wird immer der Login Dialog angezeigt. wenn ich jedoch statt der Domain die IP Adresse verwende dann geht das problemlos

 

[Till]

Ich habe genau das selbe Problem und bin auf folgendes gestoßen:

wenn ich ispconfig per FQDN aufrufe kann ich mich nicht einloggen bzw es wird immer der Login Dialog angezeigt. wenn ich jedoch statt der Domain die IP Adresse verwende dann geht das problemlos

Das klingt genau nach dem caching Problem, Das kann hartnäckig sein, z.B. reicht ein löschen des cache nichts wenn die cookies nicht gelöscht werden und dann der browser dann neu gestartet wird.

 

[madjoe1974]

hab jetzt gerade festgestellt das das problem nicht mit firefox und ie11 auftritt, aber bei chrome schon....

 

[Till]

Das Caching Problem tritt bei dem browser und hostnamen auf den Du vor dem ISPConfig Update zum Login benutzt hast. Welcher Browser und welcher Hostname das ist spielt dabei keine Rolle, es gibt keine chrome spezifischen Login probleme, ich nutze immer chrome.

 

[KurtSt]

Bei mir kann es kaum das Caching sein: Ich probiere von unterschiedlichen Browsern (Firefox und Chrome) auf unterschiedlichen Computern und habe immer dasselbe Problem:
- Password lost geht
- Falsches PW / User wird mit Fehlermeldung abgefangen
- Richtige Eingaben führen nicht weiter.
Könnte es damit zu tun haben, dass ich nur die selber generierten Zertifikate verwende? Die Browsern meckern alle, bevor man die Ausnahme bestätigt und zeigen Warnungen vor dem https:.
Hat man es aber einmal bestätigt, bleiben die Warnungen, der Browser zeigt aber obiges Verhalten.
Ich greife lokal darauf zu mit https: und der lokalen IP und :8080/login/ .

 

[madjoe1974]

Das Caching Problem tritt bei dem browser und hostnamen auf den Du vor dem ISPConfig Update zum Login benutzt hast. Welcher Browser und welcher Hostname das ist spielt dabei keine Rolle, es gibt keine chrome spezifischen Login probleme, ich nutze immer Chrome.

Tja leider kann (zumindest in diesem konkreten Fall) das aber nicht sein!!!
1.)Ich hab den Server gerade neu aufgesetzt
2.)Ich verwende Chrome seit knapp 2 Wochen, der hat heute das erste mal den ispconfig gesehen
3.)Ich hab kein update gemacht sondern eine Neuinstallation...
4.)auch nach Cache und Cookies löschen und anschließendem Rechner neustart hab ich unter Chrome das selbe verhalten!

kann es unter Umständen vielleicht wirklich an den selbst gezeichneten Zertifikaten liegen??

 

[KurtSt]

In einem älteren Posting waren einmal die Rechte in der Datenbank das Problem. Mir fiel beim Upgrade auf, dass nie nach dem DB-Passwort gefragt wurde. Müsste man hier mal suchen?

 

[florian030]

Es kann durchaus auch am Zertifikat liegen. Manche Browser sind da eigen. Du kannst es ja mal ohne https im vhost versuchen.

 

[Till]

In einem älteren Posting waren einmal die Rechte in der Datenbank das Problem. Mir fiel beim Upgrade auf, dass nie nach dem DB-Passwort gefragt wurde. Müsste man hier mal suchen?

Der updater kennt das DB passwort, es steht ja in der config Datei, daher braucht er nicht danach zu fragen. Logge Dich mal in phpmyadmin ein, geh zur dbispconfig Datenbank, markiere alle Tabellen und lass sie von phpmyadmin reparieren. Vielleicht ist die session Tabelle auf Deinem Server gecrashed.

 

[KurtSt]

Erledigt. Hat leider nichts gebracht.
Habe noch kurz in sys_session geschaut: Jeder Login-Versuch erzeugt 4 Einträge, einmal mit .."user".. und dreimal mit .."id".. lesbar in Feld session_data. Vielleicht hilft das?

 

[Till]

Editer mal bitte die Datei /usr/local/ispconfig/security/security_settings.ini und setze:

session_regenerate_id=no

 

[KurtSt]

Erledigt. Leider keine Veränderung.

 

[KurtSt]

Wo könnte ich noch suchen?
Wie eingangs geschrieben, handelt es sich um eine ältere, mehrmals upgegradete Installation.
In der DB, Tabelle sys_config finde ich:
db_version: 3.0.5.4p1
Wurde beim Upgrade auf ISPconfig 3.1.1p1 vielleicht etwas nicht angepasst?

 

[Till]

db_version gibt die ursprungsversion an, also die erstinstallation, nicht die aktuelle version. Die aktuelle dbversion findest man und der server tabelle, es handelt sich dabei um einen integer wert welcher der nummer der zuletzt eingespielten incrementellen sql patch datei entspricht.

 

[KurtSt]

Ich habe nun einen neuen Server aufgesetzt nach "The Perfect Server - Ubuntu 16.04 (Xenial Xerus) with Apache, PHP, MySQL, PureFTPD, BIND, Postfix, Dovecot and ISPConfig 3.1". Der läuft problemlos. Nach zwei Jahren Betrieb des bisherigen Servers ist dies auch eine gute Bereinigung (Neustes Ubuntu LTS, MariaDB statt MySQL).
Nun steht mir die Migration bevor, ohne dass ich auf ISPconfig des bisherigen Systems zugreifen kann. Mal sehen, ob das geht.